Effectivement il peut y avoir une confusion.
Ces mots clés existent probablement pour 2 raisons :
- syntaxe plus concise, int par exemple designant le type "System.Int32".
- proche de la syntaxe C/C++, ce qui est un des objectifs de C#.
MSDN indique clairement que ce sont 1/ des types primitifs
Ca c'est de la désinformation. Je te mets au défi de trouver le terme 'primitif' dans la page que tu cites.
Dans la page que tu références, il est indiqué que int désignait un type intégral.
Qu'est-ce qu'un type intégral ? Un type numérique.
Qu'est-ce qu'un type numérique ? C'est un type simple.
Qu'est-ce qu'un type simple ? Un type struct.
Qu'est-ce qu'un type struct ? Un type valeur.
Qu'est-ce qu'un type valeur ? un type.
(Tout cela découle de la lecture de la grammaire du langage)
Autre citation qui montre clairement que les mots clés ne sont que des raccourcis syntaxique :
"The simple types are identified through reserved words, but these reserved words are simply aliases for predefined struct types in the System namespace".
Dernière citation :
"C#’s type system is unified such that a value of any type can be treated as an object. Every type in C# directly or indirectly derives from the object class type, and object is the ultimate base class of all types."
Désinformation désinformation, faut pas en rajouter non plus :)
En C# int est effectivement un mot clé... Mais ca ne l'empêche pas d'être un objet non plus :)
Sémantiquement c'est équivalent à une déclaration d'un objet de type Int32, qui dérive explicitement de Object.
En C# il y a 2 types d'objets : les objets "valeur" et les objets "référence". Le premier type inclu tous les types primitifs tels que int, double, char, et les types déclarées comme "structure" à l'aide du mot clé "struct". Les autres sont les types déclarées comme "class", ca n'empêche pas certains mot-clés d'également référencer ce genre de type, exemple le mot-clé "string" qui est un raccourci pour "String", classe tout ce qu'il y a de plus standard.
Si t'es pas convaincu, exécute le code suivant en C# :
int i = 0;
Console.WriteLine(i is object);
Le résultat est bien évidemment True, encore heureux.
Moralité, en C# tout dérive d'Object, il y a 2 types d'objets : les classes et les structures.
Il y a "seulement" huit fois le mot "password" dans cette page. C'est ça la notion d'open de MS ?
Donnes les urls vers les documents. Pas un truc qui dit que quelque part il y a ces documents.
Oué enfin si c'est le fond qui t'intéresse et donc les modifications apportées à l'OOXML suites aux remarques de l'ISO, il est décrit dans la page que je t'ai pointé.
Je ne parle pas de l'annonce, mais de l'engage formel de MS.
Evidemment là ce n'est qu'une annonce. L'engagement formel même s'il n'existe pas encore (forcement c'est une annonce) c'est le même que pour l'OOXML, donc la forme comme le fond est connu, ils mettrons probablement la page à jour quand les specs seront dispos. Mais supposer le contraire, c'est clairement faire du FUD.
Non, Groklaw ne dit pas que ça.
Alors comment tu traduis ca puisque j'ai rien compris :
" just noticed it's not a license; it's a promise. So here's my worry: a license can be yours to keep even if Microsoft sells whatever patents it thinks it could sue you with for using its formats. But what about a promise? Couldn't the new owner of the patents say it never promised you anything?"
et ca :
"So, it's a personal promise from Microsoft to you covering Microsoft-owned or controlled patents. And if they are no longer Microsoft-owned or -controlled? "
Oui tu peux légèrement rectifier ma traduction et remplacer "autres droits" par "ces mêmes droits", ce qui ne change strictement rien au sens de l'hypothèse de Growklaw qui se résume toujours de la même façon : Quid des brevets s'ils sont détenus par une autre boîte.
Ben oui, c'est mieux que rien.
Euh, tu veux quoi de plus d'un point de vue légal ? Franchement vas-y dis le.
Groklaw parle plus spécifiquement des formats binaire .doc, .xls, etc... et considère que OSP sera appliqué.
OSP (mise à jour 10/01/2008 donc très récente), il n'y a pas les formats binaires word/excel/etc
1) L'annonce de Brian Jones a été faite après le 10/01 (le 16).
2) C'est clairement indiqué que l'Open Specification Promise s'appliquera aux formats binaires office le 15 février. En attendant cette date, tu ne peux que faire du FUD.
Je fude ?
Oui, tu émets des doutes de quelque chose qui sera effectif le 15/02.
Et notes comme beaucoup de version ne sont pas indiquées...
Si tu fais références aux specs de web-services 'WS-*', je te conseilles de lire les petites lignes :
"This promise applies to all versions of these specifications"
ca te va toujours pas ?
Arrête de fuder. Les brevets c'est la merde on le sait.
Je l'ai dit moi même que c'était du FUD, pour justement montrer que ce qu'écrivait Growklaw en était également. ca s'appelle une comparaison au cas où t'aurais pas compris. On est d'accord sur le fait que les brevets c'est de la merde.
Mais les gesticulations de MS ses derniers temps sont du vaporware. C'est d'autant plus du vaporware quand on considère l'historique de MS.
Quel est le rapport avec les vaporwares ?? Si tu veux parler de l'historique de MS en la matière, trouve moi un seul exemple où MS annonce qu'ils vont passer une spec sous "Open Specification Promise" et ne l'ont pas fait.
Notons le côté affirmation gratuite...
C'est pas une affirmation, c'est un engagement
Passons sur le FUD "la GPL n'est pas claire".
Mouarf, MS indique juste que ce n'est pas à eux de répondre à cette question, MS n'est pas juge. Affirmer quelque chose dans un sens ou dans l'autre n'aurait de toute façon aucune valeur, seul un tribunal peut en décider, et effectivement dans chaque pays une interprétation différente peut être faite suivant le contexte juridique, où est le FUD ?
MS dit que d'après d'autres personnes, que MS ne cite pas (ce qui comique), OSP est compatible avec la GPL.
Comment t'es de mauvaise foi... Quand RedHat dit : Red Hat estime que le texte de l'OSP est suffisamment souple pour permettre l'implémentation des spécifications indiquées dans les logiciels fournis sous les licences Open Source et gratuites.
Là tu vas me dire que Redhat ne parle pas spécifiquement de la GPL, c'est vrai c'est bien connu, RedHat doit pas considérer en premier lieu cette licence pour affirmer ce genre de chose... Franchement tu crois sérieusement que si RedHat voyait un problème avec cet engagement vis-à-vis de la GPL ils auraient écrit quelque chose comme la phrase ci-dessus ?
Et puis bon comme le dit très bien le mec de RedHat :
"The question asked in the Microsoft piece is whether the OSP can be trusted. As I have pointed out, that is simply a silly and irrelevant question."
Les problèmes sont ailleurs. (Le contenu des specs elles-mêmes, si elles sont techniquement implémentables, si l'implémentation de MS correspond bien aux specs, etc.)
Ces dernières sont uniquement pour le passage ISO. Il est reproché à OOXML d'utiliser les formats binaires de MS-Office et ces derniers ne sont pas documentés. Comme par hazard..., à quelques semaines du second tour ISO, MS fait des promesses.
Oué y'a de fortes chances que ce soit lié. Mais c'est le résultat qui compte. Et je vois mal MS ne pas tenir ses engagements aux 15 février, au risque de perdre toute crédibilité auprès de l'ISO. Faut vraiment être tordu pour faire ce genre d'hypothèse.
Toi tu nous dis quoi ?
Pas de problème, il y a le temps, dormé sur vos deux oreilles.
Moi je parles pas d'OOXML, je parlais à la base de l'article que tu cites, et il parle des formats binaires et de l'annonce de MS de les passer sous Open Specification Promise. Arrête de changer de sujet, même s'ils sont liés.
Je ne défend aucunement MS, c'est pas le but. Mon commentaire avait juste pour objectif de contrebalancer ce journal qui encense un article de growklaw sans aucune forme de critique.
Un autre, car ça me démange :
C'est du texte MS :
These methods include API programming calls, Office Open XML, XML, RTF, or HTML. If these methods do not address your needs, you may be eligible to participate in a Royalty-Free File Format Program and to receive technical documentation for certain Microsoft Office binary file formats.
Et ? Ca c'était avant effectivement. Justement là il y a une annonce officielle de MS comme quoi ce ne sera plus cet ancienne méthode de fourniture de documentation au compte-goutte dans des conditions particulières.
Les promesses n'engagent que ceux qui les écoutent.
C'est pas parcqu'en Français on a une phrase toute faite qu'elle démontre quoique ce soit. Que sous-entend tu ? Que MS peut ne pas respecter les engagements qu'il annonce ?
Même Groklaw ne dit pas ca. Groklaw emet juste l'hypothèse que si le format est ou devient protéger par d'autres droits non détenus par MS (genre un brevet détenu par une autre boîte), ben c'est pas couvert par cet engagement. Et je vois mal comment MS pourrait s'engager autrement sur ce point.
Même RedHat qui est le premier à taper sur MS d'un point de vue licence applaudit cette forme d'engagement :
"Red Hat believes that the text of the OSP gives sufficient flexibility to implement the listed specifications in software licensed under free and open source licenses. We commend Microsoft’s efforts to reach out to representatives from the open source community and solicit their feedback on this text, and Microsoft's willingness to make modifications in response to our comments"
La conclusion de l'article est affligeante et en dit long sur les objectifs de l'auteur :
"And if they are no longer Microsoft-owned or -controlled? "
Blablabla. Si demain on s'aperçoit que l'ODF ou je sais pas quoi est couvert par un brevet et que la boîte qui détient le brevet attaque (au pif) le projet OOo, c'est également possible. Mais ca reste également du domaine du FUD.
Le reste de l'article c'est quoi : "attention, la page n'est pas encore à jour vis-à-vis de la nouvelle version de l'OOXML qui sera filé à l'ISO, peut être même que cette version ne sera pas dedans !"
Oué bah oué, peut être. Et ? Pourquoi rappeler celà ci ce n'est chercher à semer le doute chez le lecteur sur des événements incertains du futur ? Encore du FUD.
Encore un extrait de l'article : I don't see how this works with the GPL, with the way it's distributed. Sublicensing without having to contact anyone is the rule in GPL stuff. As usual with Microsoft, the devil is in the details.
Pourquoi ca ne marcherait pas avec la GPL ? C'est clairement marqué noir sur blanc : "There is no need for sublicensing. This promise is directly applicable to you and everyone else who wants to use it."
Alors faute d'argument et d'explication, l'auteur colle des screenshots de l'ancienne méthode de diffusion des specs des formats Office (avant l'annonce récente donc). Au lecteur est laissé le soin de supposer que ca sert de preuve pour démontrer... quoi au juste ? Qu'avant cette déclaration les specs des formats Office (binaires) étaient pas dispo de manière clair pour tout le monde ? D'où l'importance des annonces récentes ! Clap clap.
Plutôt que de FUDer comme un porc, l'auteur de l'article ferait mieux d'attendre la date officielle de mise à dispo des specs comme il l'annonce lui même :
"Microsoft says it will make the release of the binary formats by February 15th. I don't see how that gives anyone time to evaluate before the ballot resolution meeting at the end of February."
Après on pourra juger et critiquer la façon dont les specs sont mises à disposition, pas la peine de FUDer avant l'heure.
Bon ben par contre Visual Studio le fait très bien avec C# : en plein milieu d'un flot d'exécution je peux mettre sur "pause", modifier le code, et appuyer sur "play" sans avoir besoin de relancer tout le flot d'exécution.
Evidemment comme pour Java y'a une VM derrière qui tourne dans un mode particulier en association avec le debuggeur, mais d'un point de vue utilisateur où est le problème ?
Cela dit concrêtement je m'en sers rarement et j'ai du mal à voir en quoi ca increase tant que ca ma productivity.
Pour l'historisation, c'est quoi la différence avec subversion+historique de l'IDE ?
Chiffre d'affaire 2006 (source wikipedia) : 40 millions de dollars.
qui ne fait pas sa rente sur des brevets et de la propriété intelectuelle
Sur les brevets, peut être pas. Sur la propriété intellectuelle, au contraire : tout le business model de MySQL AB repose sur le fait qu'ils détiennent le copyright des sources du produit MySQL (et le copyright c'est avant tout de la propriété intellectuelle) ce qui leur permet entre autre de vendre des, licences proprio.
Le fait de détenir la marque MySQL (autre propriété intellectuelle) et le copyright du code leur assure également de maîtriser les évolutions de MySQL, et donc maîtriser le support, bref de vendre du service autour de MySQL.
La GPL les aident en ce sens qu'elle assure à l'auteur de garder "la main" sur la plupart des sources de revenu qui peuvent découler de la propriété intellectuelle du code.
Le (tout) début de la fin pour la propriété intelectuelle sur du code informatique?
Adieu la GPL ?
Un lanceur c'est cool, mais : tu dois bouger ta main jusqu'à la souris, trouver l'icone, viser l'icone et cliquer. C'est pas mal non plus mais c'est totalement différent :)
Les Gnome Do et autre QuickSilver sont plutôt des descendants de la ligne de commande, adapté aux environnements graphiques et avec une notion de recherche/action.
Sans doute une histoire de limitation des compilateurs C à l'époque ou l'on avait 512Ko de mémoire.
Celà dis ce n'est pas tout à fait exact, le compilo vc++ peut par exemple faire des optimisations sur l'ensemble des .c : http://msdn2.microsoft.com/en-us/library/0zza0de8(VS.71).asp(...)
Ce n'est pas comparable à des optimisations de haut niveau je suis d'accord. Ce genre d'option a par contre l'air de limiter la réutilisation des bibliothèques éventuellement générés, d'où sa désactivation par défaut.
L'inclusion du C permet la réutilisation de lib, il ne faut pas chercher plus loin...
Certes, mais sérieusement, que cela implique-t-il au niveau du compilo pour les optimisations "globales" ?
C'est aussi l'intérêt d'un langage de haut niveau par rapport au C.
On est d'accord.
Y'a 2 niveaux de sécurité si tu veux : la JVM fourni une couche d'abstraction vis à vis de l'OS et une gestion des droits notamment pour empêcher une applet de faire n'importe quoi. Le 2ème niveau (au niveau langage) est d'éviter au programmeur de faire trop facilement des conneries qui conduisent à des plantages en lui donnait un langage avec une sémantique n'autorisant pas une gestion "manuelle" de la mémoire par exemple. Cela peut même avoir un impact en terme de sécurité contre les attaques : cas typique du buffer overrun source d'un grand nombre de faille de sécu dans des programmes écrits en C/C++.
En quoi c'est crade ? C'est ton point de vue subjectif. Techniquement ca ne limitera pas le compilo et moi j'essai de dire que ca apporte une qualité au langage.
Pour discuter entre personnes, il faut mieux un dictionnaire figé avec des définitions précises et partagées qu'un dictionnaire extensible avec des définitions personnalisées.
On ne doit pas bosser sur les mêmes projets...
Y'a de fortes chances :) Cela dit dans la plupart des projets on retrouve quand mêmes des étapes identiques : cahier des charges, analyse, spécification, conception, développement, test, validation, intégration, déploiement, maintenance, etc.
Après je sais pas quelle place occupe le dev dans tes projets...
Quand tu es au niveau d'optimisation d'une lib, tu peux déjà faire beaucoup plus que le faire par fichier .c comme le C actuellement. C'est un boulot prévus cette année, il me semble, la modularité.
Bien entendu. Mais pourquoi un compilo C le fait par fichier .c ? J'avais effectivement déjà soulevé le problème de la modularité dans le passé, content que vous l'intégriez. Cela dit il serait intéressant de mesurer le juste milieu entre modularité et gain lié à l'optimisation globale potentielle.
Je ne vois pas de quoi tu parles. De l'effort sur un programme particulier ou sur le compilo ? C'est évidement vrai pour un programme particulier. C'est faux pour le compilo dont les efforts bénéficient à tous les programmes.
On est d'accord :)
Mince tu viens d'avoir une crise d'intelligence ! C'est les 2 points essentiels qui ont amené la création de Lisaac.
Tu réponds pas à la question :) Tu as encore le point de vue du compilo et non le point de vue utilisateur.
Niveau optimisation automatique, il y a plein de choses infaisables en C : notamment, tu ne peux pas toucher le layout mémoire des données, or pour la vectorisation automatique cela peut être nécessaire. L'utilisation de pointeur te fait pointer sur un trou noir et les alias peuvent être compliqué à détecté.
On est d'accord. Mais comment allez vous gérer l'intégration avec le langage C que vous proposez dans le langage ? Dès qu'un bout de code apparaît vous désactivez quelles optimisations ?
Tu parlais de l'embarqué d'une façon un peu "à coté de la plaque". Dans l'embarqué, tu veux un code qui marche, un développement rapide, une empreinte mémoire minimum.
Mouarf. Quel ingénieur ne veut pas ca :-) Tu crois que dans l'embarqué ils ne se soucient pas du tout de la modularité, de la lisibilité du code ? Evidemment je suppose qu'on parle pas forcement de la même chose derrière le terme "embarqué", ca peut aller du robot industriel au terminal ADSL. Il y a toute une gamme de besoin et de solutions.
La gestion d'un processus et de ces droit est quand meme à la charge d'un OS
Y'a pas de vérité absolue. Y'a que des constats à des instants données. La gestion de la sécurité proposée par l'OS est grossière, la VM apporte un niveau complémentaire. De plus la VM propose un modèle de sécurité qui est justement indépendant de l'OS. C'est une lourdeur mais aussi un atout.
Quand je dis que c'est lourd de forker, c'est qu'il y a un nécessaire cloisonnement mémoire, des communications inter-processus à mettre en place. Même si pour toi une VM est lourde, le modèle de gestion mémoire et le modèle de cloisonnement qu'il propose permet d'éviter les lourdeurs techniques qu'impose les processus natif de l'OS.
Suffit de penser au scénario classique de "plugins" où des composants d'une provenance "inconnue" sont chargées dans l'application. Fait le en C et refais le en Java ou C# après, avec bien sûr des limitations pour que le plugin ne viennent pas faire n'importe quoi dans ton appli où fasse n'importe quoi sur la machine avec les droits de l'application hôte.
ne veut pas dire qu'une VM est LA solution à apporter.
C'est pas "la" solution, c'est "une" solution.
la vraie solution à apporter etait de faire évoluer les OS. C'est ce qu'a fait M$ avec .Net
Non, MS a repris exactement le même modèle d'abstraction que Java dans .NET. Et oui y'a toute la "lourdeur" liée au fait que cette VM constitue une couche d'abstraction totale de l'OS et propose un ensemble de services clés en main qui ont certain coût.
Alors pourquoi ne pas faire comme dans beaucoup de langages, à savoir rajouter des constructions qui ne seraient que du sucre syntaxique sur des libs internes non exposées ?
ai-je dis que les optimisations de haut niveau ca n'avait aucun intérêt ? Je penses jusque dans le contexte où l'on cible une VM, les gains les plus importants à chercher sont au niveau du bytecode lui même. Surtout que le modèle exposé par la VM peut limiter les possibilités d'optimisations de haut niveau (rien que le principe de réflexion).
C'est incroyable de vouloir s'enfoncer autant...
C'est incroyable cette obstination à refuser la critique...
Ontologia bosse pour un éditeur il me semble...
Et moi des études...
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.
Et... ? Où est-je dis le contraire ? J'ai juste dit que ce facteur n'a rien de révolutionnaire et d'autres langages s'amusent sur le même terrrain sans que ca soit déterminant.
Le code c'est quoi dans un projet, à allez à la louche 25% du temps ? gagner 20% de temps sur 25% d'un projet ? C'est où la révolution ?
Donc, c'est évidement un argument primordial en développement logiciel.
Sauf que vous proposez pas un facteur x3 ou 4 comme peut le faire le C par rapport à l'assembleur.
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 ?
Ah bah vi forcement, les critiques on s'en fou c'est plus simple. En tout cas ca montre clairement nos divergeances sur ce qui fait les qualités d'un langage informatique. Moi j'essai d'expliquer que le langage peut limiter les constructions trop personnalisées et diffcilement lisible par un autre programmeur. C'est d'ailleur sur ce modèle que son construit de nombreux langages : on limite volontairement les constructions de base et on ajoute celles qui sont le plus souvent utilisées (autre application des design patterns).
Pour moi c'est bien plus important que de gagner 20% de lignes de codes en moins.
toi peut-être pas...
A quoi sert cette remarque ? Tu veux pas plutôt donner un exemple plutôt que de laisser sous-etendre ?
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...
Et... ? Est-je dis le contraire ? Ca ne répond en rien à la problématique que j'ai posée concernant lea divergeance d'intérêt entre les algos d'optimisation globale et le besoin de modularité...
On a compris que tu ne comprends rien à l'optimisation, c'est pas la peine de l'étaler autant
Je suis pas spécialistes comme vous, mais j'ai quand même quelques notions pour avoir suivi des cours d'optimisation. Et des principes de bases restent pour moi toujours d'actualité : avant de chercher à optimiser, il faut voir le gain global potentiel par rapport à l'effort mis en place, c'est pour ca que j'essai de replacer dans un contexte réel les gains potentiels d'optimisation que pourrait apporter Lisaac...
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)
La question doit être posée différement : quelle est la difficulté de constuire un programme "optimale" en Lissac par rapport à la difficulité d'optimiser un code en C ?
Autre question : pourquoi les mêmes optimisations ne peuvent-elles pas être appliquées à un autre langage ?
Pourquoi tu parles de trucs qui tu ne connais pas ?
T'as émis l'hypothèse que tu comprenais pas ce que je disais ou qu'on parlait pas de la même chose ?
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 !
Comprends pas ce que tu dis.
J'imagine que pour la sécurité, tu parles de la sureté de fonctionnement et non d'attaque logiciel...
Soit tu lis une ligne sur 2 de mes commentaires, soit t'as des problèmes :) Depuis le début j'ai parlé des 2 contextes de sécurité. Pas de ma faute si c'est le même mot.
Java et C# ne le proposent pas, parce que c'est très dur à compiler, même quand tu fait du JIT.
A la base les concepteurs de Java avait volontairement fait un langage "simple" avec des constructions syntaxiques "figées" pour justement limiter ce qui se faisait en C++. Le résultat c'est quoi : on peut être expert en Java en 2 ou 3 ans quand il en faut 10 en C++.
L'argument technique n'est clairement pas suffisant. D'ailleur si le compilo de Lisaac le fait sauter, il est possible de le faire sauter également en Java ou C#.
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.
Evidemment, je ne doute pas que vous allez le faire de manière intelligente dans la lib standard. Seulement c'est pas monsieur tout le monde.
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.
Sans parler de modifier, le programmeur peut avoir envie d'ajouter, de faire sa lib. Et c'est là que c'est dangereux. Au final si la bonne pratique consiste uniquement à réutiliser les constructions standards, l'intérêt de pouvoir les personnaliser...
Comme je te l'ai déjà montré, en C# 3 tu peux obtenir plus ou moins le même type d'extensibilité et avoir du code du style :
macollection.foreach( //code ).until (//code).do(//code).finally(//code).except(//code).etc. Bref rien de nouveau sous le soleil.
La critique qui revient généralement, c'est que le code produit est certes joli, mais il devient de plus en plus difficile d'appréhender ce genre de code.
Ils ont en partie utiliser le même principe que vous, à savoir ajouter des certains mots-clé afin de standardiser des constructions courantes "select" "group" "order", qui ne sont qu'une surcouche sur une lib.
Et j'aimerai que tu me cites les constructions de Java, qui utilisent ces fameuses plus value de la VM...
L'absence de construction permettant d'aller taper n'importe où dans la mémoire permettant d'avoir une gestion de la mémoire particulière, on peut aussi citer tout ce qui concerne la méta-programmation comme la réflexion ou les attributs de méta-données.
Il suffit de réécrire un autre back-end afin que le compilateur crache du code pour une VM quelconque
Oué y'a ka fo ke. Bien sûr je ne doute pas un instant que ce soit possible, mais c'est presque inutile tellement ca sera inexploitable : comme s'interfacera ce code avec les autres langages ciblant la VM ? Comment va s'intégrer le langage au modèle particulier de sécurité et de gestion mémoire proposé par les VM ? 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 ?
Le problème de sécurité serait donc réglé.
Bof, ca suppose que t'interdise dans le langage certaines constructions tout de même. Il ne faudra pas laisser un accès n'importe où dans la mémoire. Il faudra s'intégrer avec le modèle de chargement du code, la gestion mémoire, etc. Pour moi c'est pas aussi simple que tu le crois pour m'être un peu intéressé à la compilation vers des VM.
En réécrivant le parseur, on pourrait lui faire compiler assez facilement du Java.
Ne serait-ce pas plus pertinent ? Ca rejoint mon idée plus haut qui consistait à réutiliser les atouts du compilo plutôt que de forcer à l'utilisation d'une syntaxe qui a pour moi beaucoup d'inconvénient en pratique.
le compilateur Lisaac permet de faire énormément de chose, y compris de répondre à tes problèmes de sécurité.
Moins convaincu. Tu vas pas résoudres les problèmes de sécurité qui font que potentiellement tu débordes d'un tableau sur un autre espace de la mémoire de ton process. Ca supposerait un certain nombre de limitation dans le langage ou pire ca changerait la sémantique initiale du langage.
Si t'en ai convaincu, moi je reste extrêmement dubitatif. J'attend de voir du concrêt.
mais tu as de grosses lacunes en informatique théorique.
et toi en informatique pratique. La théorie c'est bien, si elle a pour objectif d'améliorer la pratique, mes critiques ne vont que dans ce sens.
Parce que j'y crois, et te prierai de ne pas me casser mes rêves ;-)
Rêver est une chose, prendre ses désirs pour des réalités en est une autre. Ce que je te reproche ce n'est pas ton approche théorique des langages informatiques mais le ton prétentieux que tu y ajoutes. Un peu d'humilité dans l'approche servirait bien mieux tes propos, ne serait-ce qu'à cause du nombre important de langages "joli d'un point de vue théorique" qui n'ont jamais dépassé le cadre universitaire.
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.
Merci de parler enfin des réels atouts de Lisaac (même si on en avait déjà parlé dans d'autres journaux).
Cela dit je reste perplexe : la quantité de ligne de code n'est pas un critère révolutionnaire à mon sens, la première qualité de la syntaxe réside pour moi dans sa lisibilité et dans sa facilité de relecture par une tierce personne. Je critiquais le côté "trop ouvert" des constructions syntaxique de Lisaac, en précisant que pour moi c'était plus un boulet qu'un atout dans la vraie vie de programmeur... tu veux pas argumenter là dessus ?
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 ?
L'approche d'optimisation "par le bas" au niveau assembleur à l'aide de matos spécialisé a des améliorations bien plus importantes. A quoi sert de gagner 20% de temps d'encodage d'une vidéo en MPEG2 quand un encodeur hard va te faire gagner 300% de temps ?
Une piste beaucoup plus intéressante à mon sens c'est la parallélisation. Je te vois venir avec tes grands sabots, tu vas me dire que ca tombe bien Lisaac enlargeant ton penis il va aussi me permettre de paralléliser le bousin tout seul. Je veux du concrêt. Parcque le coup du "ca marche en théorie" se finit souvent par "ca marchera jamais en pratique".
- Un langage système permettant d'écrire un OS, sans nécessiter autre chose que quelques lignes d'assembleur.
Mouaich. Et vous avez résolu le problème des ressources nécessaires pour compiler le bouzin ? Parcqu'un OS c'est pas un simple encodeur.
Et le problème de la modularité ? Vous allez systématiquement devoir faire le choix entre optimisation globales qui va tendre vers du monolithique et souplesse d'architecture qui empêchera les optimisations globales et donc l'intérêt du langage.
Alors effectivement, toi, ingénieur d'informatique de gestion, tu t'en tapes des perfs, et c'est normal.
Non je m'en tapes pas, y'a pleins de moment où c'est critique. Je fais dans l'audio/vidéo, et je t'assures que ca devient problématique de faire tourner des algos de reconnaissance vidéo en temps réel sur un flux encodé en H264. Et là t'es content d'avoir des décodeurs hardware.
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.
Et à part leur promettre 20% de gains de perf potentiel, quel intérêt auront-ils à utiliser un nouveau langage ? Sachant que j'ai soulever des inconvénients qui sont valables dans le cadre de l'embarqué également : modularité, constructions syntaxique standard vs personnalisées, etc. 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...
Il est vrai que la TODOliste est encore énorme, et ce compilateur deviendra de plus en intéressant :
Pour moi le plus urgent reste de résoudre les problèmes qui ferait de Lisaac un langage utilisable. Après vous pourrez poursuivre les optimisations. Si vous partez dans des délires d'optimisations qui font gagner encore 3 ou 5% de perf par ci par là et qu'au final le principe même du langage ne répond pas aux besoins des ingénieurs, quel est l'intérêt ?
J'ai autant l'impression que les atouts de Lisaac résident dans le compilo que dans le langage, des atouts du compilo ne peuvent-ils par être repris dans d'autres langages pour les améliorer ? Ne serais- ce pas une approche plus "utile" ?
mais il a un énorme potentiel, et je veux au moins tenter l'aventure.
Moi j'ai surtout peur que vous passiez à côté de certaines qualités essentiels d'un langage de nos jours. Les perfs et la beauté du code, c'est pour moi de l'époque ancienne. Au temps des hackers. C'est toujours des critères valides dans de nombreux domaines, mais ils ne sont plus suffisant.
Sinon en master, si il y en a qui n'ont jamais fais de programmation objet à défaut de java, ils viennent d'où ? d'une licence info ? parce que c'est quand même un peu gros là.
Oué je me suis un peu perdu dans le nouveau découpage universitaire :) A l'époque je débarquais de post-DUT en licence (bac+3), donc les autres venait de l'équivalent de licence 2 math/info. Mais bon globalement en info je me suis fait chier en licence (à bac+3 donc), en maîtrise aussi parcque bon on a pris de l'avance en licence pour s'occuper, et en fait y'a qu'en dernière année qu'on avait l'impression de voir le côté "ingénieur".
Cela dit je comprend la problématique de faire apprendre de l'informatique à l'entrée en fac à des gens qui ne seront pas destinés à en faire. Cela dit j'ai plus l'impression que la question n'est pas là : j'ai l'impression qu'on fait apprendre des langages "académiques" parcque bon on sait jamais, il va peut être finir chercheur et pas ingénieur, il faut donc mieux un langage conceptuel. Mais bon dans la vraie vie c'est 90% d'ingénieurs/développeurs et pas des chercheurs. Manque de bol c'est 90% de chercheurs comme profs.
A mon avis il faudrait mieux présenter du Java (ou du Pascal ou du C, enfin un truc proche de la vraie vie quoi) même dans les premiers modules de fac : ca motiverait probablement pas les mêmes gens.
En tout cas une fois arrivée à Bac+5 on a pas du tout le même bagage technique au final, et ca se ressent à l'entrée dans le monde du travail. Heuresement, le Java est facile à apprendre sur le tas, mais faut plus espérer leur demander coder en C++ :-( Tu leur dis gentiment que ca sert à rien de mettre Scheme ou Lisp dans leur CV entreprise...
Moi ce que je vois dans ce classement, c'est ce que je constate dans la vraie vie : le support du matos se perd. Regarder la position d'ubuntu 7.10 par rapport à la 6.10 ou la 5.05. L'inverse aurait été plus logique non ?
En fait non, c'est conforme à ce que je constate : en 4 ans d'utilisation de Linux sur une même machine, la carte réseau n'a plus été supportée après je sais plus quel migration d'une fedora x à une fedora x+1 (je l'ai changé), l'installation d'une ubuntu m'a fait perdre le support du tuner TV de ma radeon AIW... et l'installation encore plus récente d'une opensuse 10.3 m'a carrement fait comprendre que ma radeon était has been (impossible de la faire marcher et c'est pas faute de bidouiller du xorg.conf). Quand j'avais acheté un écran 20" Wide, obligé de me farcir du xorg.conf pour cette résolution "non standard'' (qui existait quand même depuis 2 ans à Darty).
Alors à part l'installation d'un nouvel écran, le reste n'a été que régression de support de matos.
Voilà mon expérience, le support matos Linux, c'était mieux avant. Bon troll ;)
[^] # Re: C & Cie
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 1.
Ces mots clés existent probablement pour 2 raisons :
- syntaxe plus concise, int par exemple designant le type "System.Int32".
- proche de la syntaxe C/C++, ce qui est un des objectifs de C#.
[^] # Re: C & Cie
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 1.
Ca c'est de la désinformation. Je te mets au défi de trouver le terme 'primitif' dans la page que tu cites.
Dans la page que tu références, il est indiqué que int désignait un type intégral.
Qu'est-ce qu'un type intégral ? Un type numérique.
Qu'est-ce qu'un type numérique ? C'est un type simple.
Qu'est-ce qu'un type simple ? Un type struct.
Qu'est-ce qu'un type struct ? Un type valeur.
Qu'est-ce qu'un type valeur ? un type.
(Tout cela découle de la lecture de la grammaire du langage)
Autre citation qui montre clairement que les mots clés ne sont que des raccourcis syntaxique :
"The simple types are identified through reserved words, but these reserved words are simply aliases for predefined struct types in the System namespace".
Dernière citation :
"C#’s type system is unified such that a value of any type can be treated as an object. Every type in C# directly or indirectly derives from the object class type, and object is the ultimate base class of all types."
Source : http://download.microsoft.com/download/3/8/8/388e7205-bc10-4(...)
[^] # Re: C & Cie
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 2.
En C# int est effectivement un mot clé... Mais ca ne l'empêche pas d'être un objet non plus :)
Sémantiquement c'est équivalent à une déclaration d'un objet de type Int32, qui dérive explicitement de Object.
En C# il y a 2 types d'objets : les objets "valeur" et les objets "référence". Le premier type inclu tous les types primitifs tels que int, double, char, et les types déclarées comme "structure" à l'aide du mot clé "struct". Les autres sont les types déclarées comme "class", ca n'empêche pas certains mot-clés d'également référencer ce genre de type, exemple le mot-clé "string" qui est un raccourci pour "String", classe tout ce qu'il y a de plus standard.
Si t'es pas convaincu, exécute le code suivant en C# :
int i = 0;
Console.WriteLine(i is object);
Le résultat est bien évidemment True, encore heureux.
Moralité, en C# tout dérive d'Object, il y a 2 types d'objets : les classes et les structures.
[^] # Re: mouarf
Posté par TImaniac (site web personnel) . En réponse au journal MS champion des faux-cul.. Évalué à 1.
Donnes les urls vers les documents. Pas un truc qui dit que quelque part il y a ces documents.
Oué enfin si c'est le fond qui t'intéresse et donc les modifications apportées à l'OOXML suites aux remarques de l'ISO, il est décrit dans la page que je t'ai pointé.
Je ne parle pas de l'annonce, mais de l'engage formel de MS.
Evidemment là ce n'est qu'une annonce. L'engagement formel même s'il n'existe pas encore (forcement c'est une annonce) c'est le même que pour l'OOXML, donc la forme comme le fond est connu, ils mettrons probablement la page à jour quand les specs seront dispos. Mais supposer le contraire, c'est clairement faire du FUD.
Non, Groklaw ne dit pas que ça.
Alors comment tu traduis ca puisque j'ai rien compris :
" just noticed it's not a license; it's a promise. So here's my worry: a license can be yours to keep even if Microsoft sells whatever patents it thinks it could sue you with for using its formats. But what about a promise? Couldn't the new owner of the patents say it never promised you anything?"
et ca :
"So, it's a personal promise from Microsoft to you covering Microsoft-owned or controlled patents. And if they are no longer Microsoft-owned or -controlled? "
Oui tu peux légèrement rectifier ma traduction et remplacer "autres droits" par "ces mêmes droits", ce qui ne change strictement rien au sens de l'hypothèse de Growklaw qui se résume toujours de la même façon : Quid des brevets s'ils sont détenus par une autre boîte.
Ben oui, c'est mieux que rien.
Euh, tu veux quoi de plus d'un point de vue légal ? Franchement vas-y dis le.
Groklaw parle plus spécifiquement des formats binaire .doc, .xls, etc... et considère que OSP sera appliqué.
OSP (mise à jour 10/01/2008 donc très récente), il n'y a pas les formats binaires word/excel/etc
1) L'annonce de Brian Jones a été faite après le 10/01 (le 16).
2) C'est clairement indiqué que l'Open Specification Promise s'appliquera aux formats binaires office le 15 février. En attendant cette date, tu ne peux que faire du FUD.
Je fude ?
Oui, tu émets des doutes de quelque chose qui sera effectif le 15/02.
Et notes comme beaucoup de version ne sont pas indiquées...
Si tu fais références aux specs de web-services 'WS-*', je te conseilles de lire les petites lignes :
"This promise applies to all versions of these specifications"
ca te va toujours pas ?
Arrête de fuder. Les brevets c'est la merde on le sait.
Je l'ai dit moi même que c'était du FUD, pour justement montrer que ce qu'écrivait Growklaw en était également. ca s'appelle une comparaison au cas où t'aurais pas compris. On est d'accord sur le fait que les brevets c'est de la merde.
Mais les gesticulations de MS ses derniers temps sont du vaporware. C'est d'autant plus du vaporware quand on considère l'historique de MS.
Quel est le rapport avec les vaporwares ?? Si tu veux parler de l'historique de MS en la matière, trouve moi un seul exemple où MS annonce qu'ils vont passer une spec sous "Open Specification Promise" et ne l'ont pas fait.
Notons le côté affirmation gratuite...
C'est pas une affirmation, c'est un engagement
Passons sur le FUD "la GPL n'est pas claire".
Mouarf, MS indique juste que ce n'est pas à eux de répondre à cette question, MS n'est pas juge. Affirmer quelque chose dans un sens ou dans l'autre n'aurait de toute façon aucune valeur, seul un tribunal peut en décider, et effectivement dans chaque pays une interprétation différente peut être faite suivant le contexte juridique, où est le FUD ?
MS dit que d'après d'autres personnes, que MS ne cite pas (ce qui comique), OSP est compatible avec la GPL.
Comment t'es de mauvaise foi... Quand RedHat dit :
Red Hat estime que le texte de l'OSP est suffisamment souple pour permettre l'implémentation des spécifications indiquées dans les logiciels fournis sous les licences Open Source et gratuites.
Là tu vas me dire que Redhat ne parle pas spécifiquement de la GPL, c'est vrai c'est bien connu, RedHat doit pas considérer en premier lieu cette licence pour affirmer ce genre de chose... Franchement tu crois sérieusement que si RedHat voyait un problème avec cet engagement vis-à-vis de la GPL ils auraient écrit quelque chose comme la phrase ci-dessus ?
Et puis bon comme le dit très bien le mec de RedHat :
"The question asked in the Microsoft piece is whether the OSP can be trusted. As I have pointed out, that is simply a silly and irrelevant question."
Les problèmes sont ailleurs. (Le contenu des specs elles-mêmes, si elles sont techniquement implémentables, si l'implémentation de MS correspond bien aux specs, etc.)
Ces dernières sont uniquement pour le passage ISO. Il est reproché à OOXML d'utiliser les formats binaires de MS-Office et ces derniers ne sont pas documentés. Comme par hazard..., à quelques semaines du second tour ISO, MS fait des promesses.
Oué y'a de fortes chances que ce soit lié. Mais c'est le résultat qui compte. Et je vois mal MS ne pas tenir ses engagements aux 15 février, au risque de perdre toute crédibilité auprès de l'ISO. Faut vraiment être tordu pour faire ce genre d'hypothèse.
Toi tu nous dis quoi ?
Pas de problème, il y a le temps, dormé sur vos deux oreilles.
Moi je parles pas d'OOXML, je parlais à la base de l'article que tu cites, et il parle des formats binaires et de l'annonce de MS de les passer sous Open Specification Promise. Arrête de changer de sujet, même s'ils sont liés.
[^] # Re: Tiens...
Posté par TImaniac (site web personnel) . En réponse au journal MS champion des faux-cul.. Évalué à 2.
# mouarf
Posté par TImaniac (site web personnel) . En réponse au journal MS champion des faux-cul.. Évalué à 2.
C'est du texte MS :
These methods include API programming calls, Office Open XML, XML, RTF, or HTML. If these methods do not address your needs, you may be eligible to participate in a Royalty-Free File Format Program and to receive technical documentation for certain Microsoft Office binary file formats.
Et ? Ca c'était avant effectivement. Justement là il y a une annonce officielle de MS comme quoi ce ne sera plus cet ancienne méthode de fourniture de documentation au compte-goutte dans des conditions particulières.
Les promesses n'engagent que ceux qui les écoutent.
C'est pas parcqu'en Français on a une phrase toute faite qu'elle démontre quoique ce soit. Que sous-entend tu ? Que MS peut ne pas respecter les engagements qu'il annonce ?
Même Groklaw ne dit pas ca. Groklaw emet juste l'hypothèse que si le format est ou devient protéger par d'autres droits non détenus par MS (genre un brevet détenu par une autre boîte), ben c'est pas couvert par cet engagement. Et je vois mal comment MS pourrait s'engager autrement sur ce point.
Même RedHat qui est le premier à taper sur MS d'un point de vue licence applaudit cette forme d'engagement :
"Red Hat believes that the text of the OSP gives sufficient flexibility to implement the listed specifications in software licensed under free and open source licenses. We commend Microsoft’s efforts to reach out to representatives from the open source community and solicit their feedback on this text, and Microsoft's willingness to make modifications in response to our comments"
La conclusion de l'article est affligeante et en dit long sur les objectifs de l'auteur :
"And if they are no longer Microsoft-owned or -controlled? "
Blablabla. Si demain on s'aperçoit que l'ODF ou je sais pas quoi est couvert par un brevet et que la boîte qui détient le brevet attaque (au pif) le projet OOo, c'est également possible. Mais ca reste également du domaine du FUD.
Le reste de l'article c'est quoi : "attention, la page n'est pas encore à jour vis-à-vis de la nouvelle version de l'OOXML qui sera filé à l'ISO, peut être même que cette version ne sera pas dedans !"
Oué bah oué, peut être. Et ? Pourquoi rappeler celà ci ce n'est chercher à semer le doute chez le lecteur sur des événements incertains du futur ? Encore du FUD.
Encore un extrait de l'article :
I don't see how this works with the GPL, with the way it's distributed. Sublicensing without having to contact anyone is the rule in GPL stuff. As usual with Microsoft, the devil is in the details.
Pourquoi ca ne marcherait pas avec la GPL ? C'est clairement marqué noir sur blanc : "There is no need for sublicensing. This promise is directly applicable to you and everyone else who wants to use it."
Alors faute d'argument et d'explication, l'auteur colle des screenshots de l'ancienne méthode de diffusion des specs des formats Office (avant l'annonce récente donc). Au lecteur est laissé le soin de supposer que ca sert de preuve pour démontrer... quoi au juste ? Qu'avant cette déclaration les specs des formats Office (binaires) étaient pas dispo de manière clair pour tout le monde ? D'où l'importance des annonces récentes ! Clap clap.
Plutôt que de FUDer comme un porc, l'auteur de l'article ferait mieux d'attendre la date officielle de mise à dispo des specs comme il l'annonce lui même :
"Microsoft says it will make the release of the binary formats by February 15th. I don't see how that gives anyone time to evaluate before the ballot resolution meeting at the end of February."
Après on pourra juger et critiquer la façon dont les specs sont mises à disposition, pas la peine de FUDer avant l'heure.
où on peut voir les modifications des spécifications d'OOXML pour le second ISO ? Il me semblait que dans OOXML il y avait Open ...
Quand on cherche on trouve : http://www.ecma-international.org/news/TC45_current_work/Pro(...)
[^] # Re: Squeak like ?
Posté par TImaniac (site web personnel) . En réponse au journal Qu'est-ce qu'un outils de développement de rève ?. Évalué à 1.
Evidemment comme pour Java y'a une VM derrière qui tourne dans un mode particulier en association avec le debuggeur, mais d'un point de vue utilisateur où est le problème ?
Cela dit concrêtement je m'en sers rarement et j'ai du mal à voir en quoi ca increase tant que ca ma productivity.
Pour l'historisation, c'est quoi la différence avec subversion+historique de l'IDE ?
[^] # Re: 1 Milliard de sous
Posté par TImaniac (site web personnel) . En réponse au journal Sun rachète MySQL AB. Évalué à 2.
qui ne fait pas sa rente sur des brevets et de la propriété intelectuelle
Sur les brevets, peut être pas. Sur la propriété intellectuelle, au contraire : tout le business model de MySQL AB repose sur le fait qu'ils détiennent le copyright des sources du produit MySQL (et le copyright c'est avant tout de la propriété intellectuelle) ce qui leur permet entre autre de vendre des, licences proprio.
Le fait de détenir la marque MySQL (autre propriété intellectuelle) et le copyright du code leur assure également de maîtriser les évolutions de MySQL, et donc maîtriser le support, bref de vendre du service autour de MySQL.
La GPL les aident en ce sens qu'elle assure à l'auteur de garder "la main" sur la plupart des sources de revenu qui peuvent découler de la propriété intellectuelle du code.
Le (tout) début de la fin pour la propriété intelectuelle sur du code informatique?
Adieu la GPL ?
[^] # Re: 1 Milliard de sous
Posté par TImaniac (site web personnel) . En réponse au journal Sun rachète MySQL AB. Évalué à 3.
[^] # Re: Test
Posté par TImaniac (site web personnel) . En réponse au journal GNOME Do. Évalué à 3.
Les Gnome Do et autre QuickSilver sont plutôt des descendants de la ligne de commande, adapté aux environnements graphiques et avec une notion de recherche/action.
[^] # Re: C'est exactement ca !
Posté par TImaniac (site web personnel) . En réponse au journal Le dilemme du pirate. Évalué à 3.
[^] # Re: A quand linuxfr en IPV6 ?
Posté par TImaniac (site web personnel) . En réponse au journal IPV6 sur les dedibox !. Évalué à 4.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 1.
Celà dis ce n'est pas tout à fait exact, le compilo vc++ peut par exemple faire des optimisations sur l'ensemble des .c :
http://msdn2.microsoft.com/en-us/library/0zza0de8(VS.71).asp(...)
Ce n'est pas comparable à des optimisations de haut niveau je suis d'accord. Ce genre d'option a par contre l'air de limiter la réutilisation des bibliothèques éventuellement générés, d'où sa désactivation par défaut.
L'inclusion du C permet la réutilisation de lib, il ne faut pas chercher plus loin...
Certes, mais sérieusement, que cela implique-t-il au niveau du compilo pour les optimisations "globales" ?
C'est aussi l'intérêt d'un langage de haut niveau par rapport au C.
On est d'accord.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 1.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 1.
Pour discuter entre personnes, il faut mieux un dictionnaire figé avec des définitions précises et partagées qu'un dictionnaire extensible avec des définitions personnalisées.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Y'a de fortes chances :) Cela dit dans la plupart des projets on retrouve quand mêmes des étapes identiques : cahier des charges, analyse, spécification, conception, développement, test, validation, intégration, déploiement, maintenance, etc.
Après je sais pas quelle place occupe le dev dans tes projets...
Quand tu es au niveau d'optimisation d'une lib, tu peux déjà faire beaucoup plus que le faire par fichier .c comme le C actuellement. C'est un boulot prévus cette année, il me semble, la modularité.
Bien entendu. Mais pourquoi un compilo C le fait par fichier .c ? J'avais effectivement déjà soulevé le problème de la modularité dans le passé, content que vous l'intégriez. Cela dit il serait intéressant de mesurer le juste milieu entre modularité et gain lié à l'optimisation globale potentielle.
Je ne vois pas de quoi tu parles. De l'effort sur un programme particulier ou sur le compilo ? C'est évidement vrai pour un programme particulier. C'est faux pour le compilo dont les efforts bénéficient à tous les programmes.
On est d'accord :)
Mince tu viens d'avoir une crise d'intelligence ! C'est les 2 points essentiels qui ont amené la création de Lisaac.
Tu réponds pas à la question :) Tu as encore le point de vue du compilo et non le point de vue utilisateur.
Niveau optimisation automatique, il y a plein de choses infaisables en C : notamment, tu ne peux pas toucher le layout mémoire des données, or pour la vectorisation automatique cela peut être nécessaire. L'utilisation de pointeur te fait pointer sur un trou noir et les alias peuvent être compliqué à détecté.
On est d'accord. Mais comment allez vous gérer l'intégration avec le langage C que vous proposez dans le langage ? Dès qu'un bout de code apparaît vous désactivez quelles optimisations ?
Tu parlais de l'embarqué d'une façon un peu "à coté de la plaque". Dans l'embarqué, tu veux un code qui marche, un développement rapide, une empreinte mémoire minimum.
Mouarf. Quel ingénieur ne veut pas ca :-) Tu crois que dans l'embarqué ils ne se soucient pas du tout de la modularité, de la lisibilité du code ? Evidemment je suppose qu'on parle pas forcement de la même chose derrière le terme "embarqué", ca peut aller du robot industriel au terminal ADSL. Il y a toute une gamme de besoin et de solutions.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 1.
Y'a pas de vérité absolue. Y'a que des constats à des instants données. La gestion de la sécurité proposée par l'OS est grossière, la VM apporte un niveau complémentaire. De plus la VM propose un modèle de sécurité qui est justement indépendant de l'OS. C'est une lourdeur mais aussi un atout.
Quand je dis que c'est lourd de forker, c'est qu'il y a un nécessaire cloisonnement mémoire, des communications inter-processus à mettre en place. Même si pour toi une VM est lourde, le modèle de gestion mémoire et le modèle de cloisonnement qu'il propose permet d'éviter les lourdeurs techniques qu'impose les processus natif de l'OS.
Suffit de penser au scénario classique de "plugins" où des composants d'une provenance "inconnue" sont chargées dans l'application. Fait le en C et refais le en Java ou C# après, avec bien sûr des limitations pour que le plugin ne viennent pas faire n'importe quoi dans ton appli où fasse n'importe quoi sur la machine avec les droits de l'application hôte.
ne veut pas dire qu'une VM est LA solution à apporter.
C'est pas "la" solution, c'est "une" solution.
la vraie solution à apporter etait de faire évoluer les OS. C'est ce qu'a fait M$ avec .Net
Non, MS a repris exactement le même modèle d'abstraction que Java dans .NET. Et oui y'a toute la "lourdeur" liée au fait que cette VM constitue une couche d'abstraction totale de l'OS et propose un ensemble de services clés en main qui ont certain coût.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 1.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
C'est incroyable cette obstination à refuser la critique...
Ontologia bosse pour un éditeur il me semble...
Et moi des études...
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.
Et... ? Où est-je dis le contraire ? J'ai juste dit que ce facteur n'a rien de révolutionnaire et d'autres langages s'amusent sur le même terrrain sans que ca soit déterminant.
Le code c'est quoi dans un projet, à allez à la louche 25% du temps ? gagner 20% de temps sur 25% d'un projet ? C'est où la révolution ?
Donc, c'est évidement un argument primordial en développement logiciel.
Sauf que vous proposez pas un facteur x3 ou 4 comme peut le faire le C par rapport à l'assembleur.
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 ?
Ah bah vi forcement, les critiques on s'en fou c'est plus simple. En tout cas ca montre clairement nos divergeances sur ce qui fait les qualités d'un langage informatique. Moi j'essai d'expliquer que le langage peut limiter les constructions trop personnalisées et diffcilement lisible par un autre programmeur. C'est d'ailleur sur ce modèle que son construit de nombreux langages : on limite volontairement les constructions de base et on ajoute celles qui sont le plus souvent utilisées (autre application des design patterns).
Pour moi c'est bien plus important que de gagner 20% de lignes de codes en moins.
toi peut-être pas...
A quoi sert cette remarque ? Tu veux pas plutôt donner un exemple plutôt que de laisser sous-etendre ?
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...
Et... ? Est-je dis le contraire ? Ca ne répond en rien à la problématique que j'ai posée concernant lea divergeance d'intérêt entre les algos d'optimisation globale et le besoin de modularité...
On a compris que tu ne comprends rien à l'optimisation, c'est pas la peine de l'étaler autant
Je suis pas spécialistes comme vous, mais j'ai quand même quelques notions pour avoir suivi des cours d'optimisation. Et des principes de bases restent pour moi toujours d'actualité : avant de chercher à optimiser, il faut voir le gain global potentiel par rapport à l'effort mis en place, c'est pour ca que j'essai de replacer dans un contexte réel les gains potentiels d'optimisation que pourrait apporter Lisaac...
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)
La question doit être posée différement : quelle est la difficulté de constuire un programme "optimale" en Lissac par rapport à la difficulité d'optimiser un code en C ?
Autre question : pourquoi les mêmes optimisations ne peuvent-elles pas être appliquées à un autre langage ?
Pourquoi tu parles de trucs qui tu ne connais pas ?
T'as émis l'hypothèse que tu comprenais pas ce que je disais ou qu'on parlait pas de la même chose ?
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 !
Comprends pas ce que tu dis.
J'imagine que pour la sécurité, tu parles de la sureté de fonctionnement et non d'attaque logiciel...
Soit tu lis une ligne sur 2 de mes commentaires, soit t'as des problèmes :) Depuis le début j'ai parlé des 2 contextes de sécurité. Pas de ma faute si c'est le même mot.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 1.
A la base les concepteurs de Java avait volontairement fait un langage "simple" avec des constructions syntaxiques "figées" pour justement limiter ce qui se faisait en C++. Le résultat c'est quoi : on peut être expert en Java en 2 ou 3 ans quand il en faut 10 en C++.
L'argument technique n'est clairement pas suffisant. D'ailleur si le compilo de Lisaac le fait sauter, il est possible de le faire sauter également en Java ou C#.
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.
Evidemment, je ne doute pas que vous allez le faire de manière intelligente dans la lib standard. Seulement c'est pas monsieur tout le monde.
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.
Sans parler de modifier, le programmeur peut avoir envie d'ajouter, de faire sa lib. Et c'est là que c'est dangereux. Au final si la bonne pratique consiste uniquement à réutiliser les constructions standards, l'intérêt de pouvoir les personnaliser...
Comme je te l'ai déjà montré, en C# 3 tu peux obtenir plus ou moins le même type d'extensibilité et avoir du code du style :
macollection.foreach( //code ).until (//code).do(//code).finally(//code).except(//code).etc. Bref rien de nouveau sous le soleil.
La critique qui revient généralement, c'est que le code produit est certes joli, mais il devient de plus en plus difficile d'appréhender ce genre de code.
Ils ont en partie utiliser le même principe que vous, à savoir ajouter des certains mots-clé afin de standardiser des constructions courantes "select" "group" "order", qui ne sont qu'une surcouche sur une lib.
Et j'aimerai que tu me cites les constructions de Java, qui utilisent ces fameuses plus value de la VM...
L'absence de construction permettant d'aller taper n'importe où dans la mémoire permettant d'avoir une gestion de la mémoire particulière, on peut aussi citer tout ce qui concerne la méta-programmation comme la réflexion ou les attributs de méta-données.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 1.
Oué y'a ka fo ke. Bien sûr je ne doute pas un instant que ce soit possible, mais c'est presque inutile tellement ca sera inexploitable : comme s'interfacera ce code avec les autres langages ciblant la VM ? Comment va s'intégrer le langage au modèle particulier de sécurité et de gestion mémoire proposé par les VM ? 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 ?
Le problème de sécurité serait donc réglé.
Bof, ca suppose que t'interdise dans le langage certaines constructions tout de même. Il ne faudra pas laisser un accès n'importe où dans la mémoire. Il faudra s'intégrer avec le modèle de chargement du code, la gestion mémoire, etc. Pour moi c'est pas aussi simple que tu le crois pour m'être un peu intéressé à la compilation vers des VM.
En réécrivant le parseur, on pourrait lui faire compiler assez facilement du Java.
Ne serait-ce pas plus pertinent ? Ca rejoint mon idée plus haut qui consistait à réutiliser les atouts du compilo plutôt que de forcer à l'utilisation d'une syntaxe qui a pour moi beaucoup d'inconvénient en pratique.
le compilateur Lisaac permet de faire énormément de chose, y compris de répondre à tes problèmes de sécurité.
Moins convaincu. Tu vas pas résoudres les problèmes de sécurité qui font que potentiellement tu débordes d'un tableau sur un autre espace de la mémoire de ton process. Ca supposerait un certain nombre de limitation dans le langage ou pire ca changerait la sémantique initiale du langage.
Si t'en ai convaincu, moi je reste extrêmement dubitatif. J'attend de voir du concrêt.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 1.
et toi en informatique pratique. La théorie c'est bien, si elle a pour objectif d'améliorer la pratique, mes critiques ne vont que dans ce sens.
Parce que j'y crois, et te prierai de ne pas me casser mes rêves ;-)
Rêver est une chose, prendre ses désirs pour des réalités en est une autre. Ce que je te reproche ce n'est pas ton approche théorique des langages informatiques mais le ton prétentieux que tu y ajoutes. Un peu d'humilité dans l'approche servirait bien mieux tes propos, ne serait-ce qu'à cause du nombre important de langages "joli d'un point de vue théorique" qui n'ont jamais dépassé le cadre universitaire.
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.
Merci de parler enfin des réels atouts de Lisaac (même si on en avait déjà parlé dans d'autres journaux).
Cela dit je reste perplexe : la quantité de ligne de code n'est pas un critère révolutionnaire à mon sens, la première qualité de la syntaxe réside pour moi dans sa lisibilité et dans sa facilité de relecture par une tierce personne. Je critiquais le côté "trop ouvert" des constructions syntaxique de Lisaac, en précisant que pour moi c'était plus un boulet qu'un atout dans la vraie vie de programmeur... tu veux pas argumenter là dessus ?
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 ?
L'approche d'optimisation "par le bas" au niveau assembleur à l'aide de matos spécialisé a des améliorations bien plus importantes. A quoi sert de gagner 20% de temps d'encodage d'une vidéo en MPEG2 quand un encodeur hard va te faire gagner 300% de temps ?
Une piste beaucoup plus intéressante à mon sens c'est la parallélisation. Je te vois venir avec tes grands sabots, tu vas me dire que ca tombe bien Lisaac enlargeant ton penis il va aussi me permettre de paralléliser le bousin tout seul. Je veux du concrêt. Parcque le coup du "ca marche en théorie" se finit souvent par "ca marchera jamais en pratique".
- Un langage système permettant d'écrire un OS, sans nécessiter autre chose que quelques lignes d'assembleur.
Mouaich. Et vous avez résolu le problème des ressources nécessaires pour compiler le bouzin ? Parcqu'un OS c'est pas un simple encodeur.
Et le problème de la modularité ? Vous allez systématiquement devoir faire le choix entre optimisation globales qui va tendre vers du monolithique et souplesse d'architecture qui empêchera les optimisations globales et donc l'intérêt du langage.
Alors effectivement, toi, ingénieur d'informatique de gestion, tu t'en tapes des perfs, et c'est normal.
Non je m'en tapes pas, y'a pleins de moment où c'est critique. Je fais dans l'audio/vidéo, et je t'assures que ca devient problématique de faire tourner des algos de reconnaissance vidéo en temps réel sur un flux encodé en H264. Et là t'es content d'avoir des décodeurs hardware.
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.
Et à part leur promettre 20% de gains de perf potentiel, quel intérêt auront-ils à utiliser un nouveau langage ? Sachant que j'ai soulever des inconvénients qui sont valables dans le cadre de l'embarqué également : modularité, constructions syntaxique standard vs personnalisées, etc. 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...
Il est vrai que la TODOliste est encore énorme, et ce compilateur deviendra de plus en intéressant :
Pour moi le plus urgent reste de résoudre les problèmes qui ferait de Lisaac un langage utilisable. Après vous pourrez poursuivre les optimisations. Si vous partez dans des délires d'optimisations qui font gagner encore 3 ou 5% de perf par ci par là et qu'au final le principe même du langage ne répond pas aux besoins des ingénieurs, quel est l'intérêt ?
J'ai autant l'impression que les atouts de Lisaac résident dans le compilo que dans le langage, des atouts du compilo ne peuvent-ils par être repris dans d'autres langages pour les améliorer ? Ne serais- ce pas une approche plus "utile" ?
mais il a un énorme potentiel, et je veux au moins tenter l'aventure.
Moi j'ai surtout peur que vous passiez à côté de certaines qualités essentiels d'un langage de nos jours. Les perfs et la beauté du code, c'est pour moi de l'époque ancienne. Au temps des hackers. C'est toujours des critères valides dans de nombreux domaines, mais ils ne sont plus suffisant.
[^] # Re: Intéressant
Posté par TImaniac (site web personnel) . En réponse au journal Troll de l'année ou coup de bluff ?. Évalué à 1.
Oué je me suis un peu perdu dans le nouveau découpage universitaire :) A l'époque je débarquais de post-DUT en licence (bac+3), donc les autres venait de l'équivalent de licence 2 math/info. Mais bon globalement en info je me suis fait chier en licence (à bac+3 donc), en maîtrise aussi parcque bon on a pris de l'avance en licence pour s'occuper, et en fait y'a qu'en dernière année qu'on avait l'impression de voir le côté "ingénieur".
Cela dit je comprend la problématique de faire apprendre de l'informatique à l'entrée en fac à des gens qui ne seront pas destinés à en faire. Cela dit j'ai plus l'impression que la question n'est pas là : j'ai l'impression qu'on fait apprendre des langages "académiques" parcque bon on sait jamais, il va peut être finir chercheur et pas ingénieur, il faut donc mieux un langage conceptuel. Mais bon dans la vraie vie c'est 90% d'ingénieurs/développeurs et pas des chercheurs. Manque de bol c'est 90% de chercheurs comme profs.
A mon avis il faudrait mieux présenter du Java (ou du Pascal ou du C, enfin un truc proche de la vraie vie quoi) même dans les premiers modules de fac : ca motiverait probablement pas les mêmes gens.
En tout cas une fois arrivée à Bac+5 on a pas du tout le même bagage technique au final, et ca se ressent à l'entrée dans le monde du travail. Heuresement, le Java est facile à apprendre sur le tas, mais faut plus espérer leur demander coder en C++ :-( Tu leur dis gentiment que ca sert à rien de mettre Scheme ou Lisp dans leur CV entreprise...
# c pas fo
Posté par TImaniac (site web personnel) . En réponse au journal Nouvelle stat sur hardware4linux.info. Évalué à 2.
En fait non, c'est conforme à ce que je constate : en 4 ans d'utilisation de Linux sur une même machine, la carte réseau n'a plus été supportée après je sais plus quel migration d'une fedora x à une fedora x+1 (je l'ai changé), l'installation d'une ubuntu m'a fait perdre le support du tuner TV de ma radeon AIW... et l'installation encore plus récente d'une opensuse 10.3 m'a carrement fait comprendre que ma radeon était has been (impossible de la faire marcher et c'est pas faute de bidouiller du xorg.conf). Quand j'avais acheté un écran 20" Wide, obligé de me farcir du xorg.conf pour cette résolution "non standard'' (qui existait quand même depuis 2 ans à Darty).
Alors à part l'installation d'un nouvel écran, le reste n'a été que régression de support de matos.
Voilà mon expérience, le support matos Linux, c'était mieux avant. Bon troll ;)