C'est gentil ça, ça me touche beaucoup :-)
Nicolas a en grande partie répondu à ta question.
Le GC est désactivable, et pour donner un exemple, il est désactivé dans le code du compilateur, au profit d'une gestion à la main assez rigoureuse. Comme tout est en lib, on peut tout à fait définir le delete de c++.
Benoit répète souvent "pas d'allocation à l'insu du programmeur", chose dont je comprend qu'il y a surement un intéret, mais dont je me fiche un peu et qui m'oblige à réfréner mes ardeurs à vouloir implémenter des features très haut niveau dans le langage ;-)
Donc comme disait Nicolas, tu peux faire ce que tu veux avec le GC, et je suis bien d'accord que ça dépend de la situation. Vu la cible de Lisaac (Embarqué, système), il risque de pas servir si souvent que ça....
Alors je répond à ta question, parce que c'est gentillement demandé et que ça a commencé à flipper sur la ML Lisaac.
De ce que j'ai compris de ce langage, particulièrement à lire http://golang.org/doc/go_for_cpp_programmers.html qui est vraiment instructif :
- Le système "objet" est marrant, original, mais j'imagine un peu limité.
En gros ça consiste à déclarer que des interfaces (ie des objets avec que des méthodes vides), et de dire qu'un truc est du type de cet objet si tu écrit une (ou plutot les) méthode qui appartient(nnent) à l'interface. Bon.. Je sens que ce genre d'approche c'est limité, et même limité ça peut péter au runtime.
Enfin on verra.
- Pas d'assertions ni d'exeptions. Bonjour le debug
- Compilation séparée, bonjour les perfs, surtout que là avec un embryon d'objet ça va commencer à poser quelques problèmes niveau perfs... T'as pas de VM pour rattraper le coup ici...
- Pas de redef des opérateurs. Change pas cela dit, par rapport à ce que la plupart des gens connaissent. (Nous, en Lisaac, on est assez fière de pouvoir écrire 45_020_089/8!.print )
- Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?
- Concurrence : correspond bien à l'état de l'art. Ca sera déterminant pour aider le langage à progresser.
Mais je pense que ce langage va marcher, car il rempli bien les condition définies par Richard P. Gabriel ( Models of Software Acceptance ) http://www.dreamsongs.com/Files/AcceptanceModels.pdf (relire cette présentation, c'est fabuleux !!) :
- Langage accessible sans nécessiter trop d'abstractions
- Gurus derrière
- Grosse boite derrière (pas de gambler ruin possible)
- Langage ressemblant à l'existant
- Langage au design relativement simple, cohérent et suffisant pour sa cible.
Plus généralement, c'est un langage construit à base de techno disponible dans l'industrie, donc un peu dépassée par ce qui se fait dans la recherche. C'est une approche pragmatique, mais qui a pas mal de limites.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Ontologia (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 9.
Nicolas a en grande partie répondu à ta question.
Le GC est désactivable, et pour donner un exemple, il est désactivé dans le code du compilateur, au profit d'une gestion à la main assez rigoureuse. Comme tout est en lib, on peut tout à fait définir le delete de c++.
Benoit répète souvent "pas d'allocation à l'insu du programmeur", chose dont je comprend qu'il y a surement un intéret, mais dont je me fiche un peu et qui m'oblige à réfréner mes ardeurs à vouloir implémenter des features très haut niveau dans le langage ;-)
Donc comme disait Nicolas, tu peux faire ce que tu veux avec le GC, et je suis bien d'accord que ça dépend de la situation. Vu la cible de Lisaac (Embarqué, système), il risque de pas servir si souvent que ça....
Alors je répond à ta question, parce que c'est gentillement demandé et que ça a commencé à flipper sur la ML Lisaac.
De ce que j'ai compris de ce langage, particulièrement à lire http://golang.org/doc/go_for_cpp_programmers.html qui est vraiment instructif :
- Le système "objet" est marrant, original, mais j'imagine un peu limité.
En gros ça consiste à déclarer que des interfaces (ie des objets avec que des méthodes vides), et de dire qu'un truc est du type de cet objet si tu écrit une (ou plutot les) méthode qui appartient(nnent) à l'interface. Bon.. Je sens que ce genre d'approche c'est limité, et même limité ça peut péter au runtime.
Enfin on verra.
- Pas d'assertions ni d'exeptions. Bonjour le debug
- Compilation séparée, bonjour les perfs, surtout que là avec un embryon d'objet ça va commencer à poser quelques problèmes niveau perfs... T'as pas de VM pour rattraper le coup ici...
- Pas de redef des opérateurs. Change pas cela dit, par rapport à ce que la plupart des gens connaissent. (Nous, en Lisaac, on est assez fière de pouvoir écrire 45_020_089/8!.print )
- Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?
- Concurrence : correspond bien à l'état de l'art. Ca sera déterminant pour aider le langage à progresser.
Mais je pense que ce langage va marcher, car il rempli bien les condition définies par Richard P. Gabriel ( Models of Software Acceptance ) http://www.dreamsongs.com/Files/AcceptanceModels.pdf (relire cette présentation, c'est fabuleux !!) :
- Langage accessible sans nécessiter trop d'abstractions
- Gurus derrière
- Grosse boite derrière (pas de gambler ruin possible)
- Langage ressemblant à l'existant
- Langage au design relativement simple, cohérent et suffisant pour sa cible.
Plus généralement, c'est un langage construit à base de techno disponible dans l'industrie, donc un peu dépassée par ce qui se fait dans la recherche. C'est une approche pragmatique, mais qui a pas mal de limites.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker