Mais c'est une véritable interview! J'aurais dû prendre ma cravate ;)
- Shootout: quelqu'un vient de suggérer la même chose sur IRC =) C'est à considérer. Cependant, il y a des énormes possibilités d'optimisations qui ne sont pas encore implémentées (je pense notamment à la spécialisation de types génériques au temps de l'exécution, pour les initiés), et donc je ne sais pas trop comment ooc se comparerait si on utilise beaucoup les collections. A suivre, je dirais.
- Rendre le développement des programmes long? Au niveau des temps de compilation? Pour cela il y a la recompilation partielle, qui permet de recompiler uniquement les modules qui ont changé. C'est un gain de temps très apréciable. D'autre part, nous envisageons de développer une REPL, ce qui permettait de modifier un programme pendant son exécution et ainsi avoir quasi le même confort qu'un langage interprété. Au niveau de la concurrence (e.g. le parallélisme, pas la rivalité ^^), c'est un sujet qui soulève bien des discussions dans la communauté. Nous ne sommes pas fixés sur une solution définitive, nous préférons nous donner du temps pour expérimenter et tester les différentes variantes afin de choisir celle qui nous semble la meilleure.
- Absolument, l'utilisation d'ooc côté serveur est tout à fait intéressante, et il semble y avoir une vague d'intérêt dans ce sens-là (nouveaux contributeurs à ooc-web/ooc-couchdb, etc.)
- Pour rebondir sur la question précédente, ooc a plutôt vocation de rester un langage généraliste. Personellement j'essaie (entre autres) d'explorer son utilisation dans le développement de jeux vidéos (en conciliant une grande flexibilité avec la performance), mais le langage reste un bon substitut à Java/C# dans la plupart des cas, si l'on souhaite un runtime plus léger et une compilation native. ooc présente aussi une alternative intéressante au C sur les plateformes embarquées, même s'il reste des progrès à faire de ce côté là, des collaborations sont en cours pour mieux adapter ooc pour l'embarqué, notamment un sdk allégé.
Merci pour les encouragements, quoi qu'il se passe, nous continuerons à vous tenir au courant!
[^] # Re: Joli
Posté par Amos Wenger . En réponse à la dépêche Le langage ooc auto-hébergé - les nouveautés de rock 0.9.0. Évalué à 8.
- Shootout: quelqu'un vient de suggérer la même chose sur IRC =) C'est à considérer. Cependant, il y a des énormes possibilités d'optimisations qui ne sont pas encore implémentées (je pense notamment à la spécialisation de types génériques au temps de l'exécution, pour les initiés), et donc je ne sais pas trop comment ooc se comparerait si on utilise beaucoup les collections. A suivre, je dirais.
- Rendre le développement des programmes long? Au niveau des temps de compilation? Pour cela il y a la recompilation partielle, qui permet de recompiler uniquement les modules qui ont changé. C'est un gain de temps très apréciable. D'autre part, nous envisageons de développer une REPL, ce qui permettait de modifier un programme pendant son exécution et ainsi avoir quasi le même confort qu'un langage interprété. Au niveau de la concurrence (e.g. le parallélisme, pas la rivalité ^^), c'est un sujet qui soulève bien des discussions dans la communauté. Nous ne sommes pas fixés sur une solution définitive, nous préférons nous donner du temps pour expérimenter et tester les différentes variantes afin de choisir celle qui nous semble la meilleure.
- Absolument, l'utilisation d'ooc côté serveur est tout à fait intéressante, et il semble y avoir une vague d'intérêt dans ce sens-là (nouveaux contributeurs à ooc-web/ooc-couchdb, etc.)
- Pour rebondir sur la question précédente, ooc a plutôt vocation de rester un langage généraliste. Personellement j'essaie (entre autres) d'explorer son utilisation dans le développement de jeux vidéos (en conciliant une grande flexibilité avec la performance), mais le langage reste un bon substitut à Java/C# dans la plupart des cas, si l'on souhaite un runtime plus léger et une compilation native. ooc présente aussi une alternative intéressante au C sur les plateformes embarquées, même s'il reste des progrès à faire de ce côté là, des collaborations sont en cours pour mieux adapter ooc pour l'embarqué, notamment un sdk allégé.
Merci pour les encouragements, quoi qu'il se passe, nous continuerons à vous tenir au courant!