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.
[^] # 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.