Dans tous compilateur utilisant de la compilation globale (Smarteiffel, Pypy peut être, Lisaac, et bien d'autres), tu bénéficies d'ors et déjà des optims sur le bouts de code que tu utilises, par rapport à des langages à JIT (ou AOT). Ie. Toute l'utilisation de ta lib est optimisée par le compilateur qui :
- N'embarque que le code que tu utilise dans ta lib
- Optimise l'utilisation de celui-ci
Donc même si ton noyau est un petit morceau de code (et heureusement), il est déjà assez gros pour que tu profite d'un gain plus que substanciel par rapport à de la compilation séparée.
Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
Explique moi un peu mieux, parce que si tu codes un kernel en C, tu fais de la compilation séparée, avec le défaut de perf qui vient avec (mais C est tellement bas niveau que ça ne se voit pas trop, tout est fait à la main). Dans un langage à compilation globale (je répète, SMartEiffel, Lisaac et d'autres), tu as toujours la possibilité de compiler globalement tes petits bouts, ce qui ne te fera perdre aucun avantage par rapport à C, tout en gagnant le haut niveau (des collections type array, liste chainées, tables de hashage, etc...)
\o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
J'attend aussi de voir le débuggueur...
Ils font comment quand ils développent en C/C++ ?
Je te rappelle que le but du projet, c'est l'embarqué, pas d'être un concurrent de Java et C# pour des logiciels de gestion.
De plus, c'est débile comme argument :
Dans la SSII où je travaille, on utilise maven. Alors c'est clairement plus sophistiqué que Makefile, d"accord, mais c'est tout aussi bloat et lent.
Et lors du debug, c'est toujours aussi peu maniable à utiliser (souvent le temps d'aller chercher un café, le temps que ça compile). Le seul intérêt étant le tracage à la main dans Eclipse, et le watching sur les variables.
En SmartEiffel (compilation globale), Ils l'ont ! Certes pas couplés à Eclipse, mais ce ne serait pas un énorme boulot, car il s'agirait juste d'interpréter du mode texte. Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
Pour les tests, tu as la programmation par contrat, ainsi qu'une lib de tests unitaires, et je parle pour SmartEiffel aussi.
Pour la documentation, tu as un outil dans chaque langage pour générer de la doc, qui ressemble à une javadoc d'ailleurs.
Tu as un debugger intégré en SmartEiffel, embarqué dans le code.
Pour le dev en équipe, le nouveau système (LIP) est fonctionnel, et il a juste besoin d'être un peu maturé pour s'assurer que même les cas les plus tordus ne posent pas problèmes.
Donc, j'aimerai bien que tu m'expliques en quoi il faut absolument de la compilation séparée pour être un langage "moderne" couvrant les problèmes de "dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement."
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
- N'embarque que le code que tu utilise dans ta lib
- Optimise l'utilisation de celui-ci
Donc même si ton noyau est un petit morceau de code (et heureusement), il est déjà assez gros pour que tu profite d'un gain plus que substanciel par rapport à de la compilation séparée.
Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
Explique moi un peu mieux, parce que si tu codes un kernel en C, tu fais de la compilation séparée, avec le défaut de perf qui vient avec (mais C est tellement bas niveau que ça ne se voit pas trop, tout est fait à la main). Dans un langage à compilation globale (je répète, SMartEiffel, Lisaac et d'autres), tu as toujours la possibilité de compiler globalement tes petits bouts, ce qui ne te fera perdre aucun avantage par rapport à C, tout en gagnant le haut niveau (des collections type array, liste chainées, tables de hashage, etc...)
De plus, pour info, il existe pas mal de techniques pour faire de la compilation globale à partir de compilation séparée
par exemple :
http://www2.lifl.fr/lmo2004/slides_lmo2004/privat.pdf
http://docs.google.com/gview?a=v&q=cache:onvvYLCD35UJ:ww(...)
\o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
J'attend aussi de voir le débuggueur...
Ils font comment quand ils développent en C/C++ ?
Je te rappelle que le but du projet, c'est l'embarqué, pas d'être un concurrent de Java et C# pour des logiciels de gestion.
De plus, c'est débile comme argument :
Dans la SSII où je travaille, on utilise maven. Alors c'est clairement plus sophistiqué que Makefile, d"accord, mais c'est tout aussi bloat et lent.
Et lors du debug, c'est toujours aussi peu maniable à utiliser (souvent le temps d'aller chercher un café, le temps que ça compile). Le seul intérêt étant le tracage à la main dans Eclipse, et le watching sur les variables.
En SmartEiffel (compilation globale), Ils l'ont ! Certes pas couplés à Eclipse, mais ce ne serait pas un énorme boulot, car il s'agirait juste d'interpréter du mode texte.
Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
Pour les tests, tu as la programmation par contrat, ainsi qu'une lib de tests unitaires, et je parle pour SmartEiffel aussi.
Pour la documentation, tu as un outil dans chaque langage pour générer de la doc, qui ressemble à une javadoc d'ailleurs.
Tu as un debugger intégré en SmartEiffel, embarqué dans le code.
Pour le dev en équipe, le nouveau système (LIP) est fonctionnel, et il a juste besoin d'être un peu maturé pour s'assurer que même les cas les plus tordus ne posent pas problèmes.
Donc, j'aimerai bien que tu m'expliques en quoi il faut absolument de la compilation séparée pour être un langage "moderne" couvrant les problèmes de "dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement."
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker