Je ne suis pas totalement d'accord avec Gniarf. Disons au préalable que j'ai fais beaucoup de Tcl dans les années 90, ayant même donné une petite dizaine de formation sur ce langage. Depuis que je suis passé totalement dans l'administration système, je fais du Perl avec beaucoup de plaisir.
Mon avis est que Tcl est et reste un très bon langage de colle pour monter au sein d'une même application des librairies métiers très différentes. Le résultat est beaucoup plus simple a appréhender que Perl, car c'est un langage que je qualifie de régulier. L'ensemble du langage tiens en 11 règles, le reste c'est juste des commandes. C'était le contenu de ma formation: à la fin de la première demi-journée (oui, bien demi-journée) le langage était connu par les élèves. Ensuite on ne faisait qu'avancer dans l'utilisation des commandes pour finir par monter une petite application complète en 3 jours.
C'est très bien pour un ingénieur non-informaticien ayant à résoudre un problème d'automatisation de processus par exemple. 90% de son temps est passé à faire autre chose que de la programmation. Le langage utilisé doit rester simple et surtout facile à se rappeler quand on s'y remet 3 mois après (je ne parle pas de reprendre un script, je parle de refaire de la programmation pendant 2 jours quand on a passé 3 mois à faire autre chose). Je ne parle même pas de Php. Reste Python et Ruby, mais l'orientation objet est loin d'être facile à maitriser pour quelqu'un qui ne fait pas de la programmation très régulièrement.
Disons que Tcl souffre à mon avis de 2 points noirs techniques à la base: le fait d'avoir comme terminaison d'instruction le retour-chariot en plus du point-virgule. Ca gêne beaucoup l'écriture et lui donne un aspect shell-like qui déplait à beaucoup. Ensuite et surtout de ne pas avoir à l'origine un type de données quelconque qui permet de construire facilement des structures complexes. En Perl, un scalaire peut être une référence quelconque, et les instructions se débrouillent très bien avec. Impossible avec Tcl de base.
Par la suite, l'introduction des namespaces a permis de faire des choses, mais la aussi il y a eut un ratage avec l'obligation d'utiliser les ::. Si le séparateur avait été l'espace, il aurait été facile de faire des objets et instances d'objets qui se comportent comme des références de données complexes, avec un mécanisme intégré au langage, et non pas apporté par une extension (IncrTcl).
Enfin, l'attitude d'Ousterhout a bloqué à mon avis les évolutions surtout de Tk, ce qui a diminué fortement l'intérêt des développeurs d'interface graphique portables. Dommage.
Mais sinon: dès 1996, Tcl/TK supportait Unicode, était complément portable sur Windows, Unix et Mac, il y avait un plugin complet pour Netscape 4, un mécanisme de Thread intégré, de sous-interpréteur avec "sand-boxing" et escalade des privilèges ou équivalents, des extensions objets, .... C'était quand même vachement bien pour l'époque, non ?
[^] # Re: Quel est l'avenir de tcl/tk ?
Posté par Joël Saunier . En réponse à la dépêche Conférence EuroTcl 2010. Évalué à 4.
Mon avis est que Tcl est et reste un très bon langage de colle pour monter au sein d'une même application des librairies métiers très différentes. Le résultat est beaucoup plus simple a appréhender que Perl, car c'est un langage que je qualifie de régulier. L'ensemble du langage tiens en 11 règles, le reste c'est juste des commandes. C'était le contenu de ma formation: à la fin de la première demi-journée (oui, bien demi-journée) le langage était connu par les élèves. Ensuite on ne faisait qu'avancer dans l'utilisation des commandes pour finir par monter une petite application complète en 3 jours.
C'est très bien pour un ingénieur non-informaticien ayant à résoudre un problème d'automatisation de processus par exemple. 90% de son temps est passé à faire autre chose que de la programmation. Le langage utilisé doit rester simple et surtout facile à se rappeler quand on s'y remet 3 mois après (je ne parle pas de reprendre un script, je parle de refaire de la programmation pendant 2 jours quand on a passé 3 mois à faire autre chose). Je ne parle même pas de Php. Reste Python et Ruby, mais l'orientation objet est loin d'être facile à maitriser pour quelqu'un qui ne fait pas de la programmation très régulièrement.
Disons que Tcl souffre à mon avis de 2 points noirs techniques à la base: le fait d'avoir comme terminaison d'instruction le retour-chariot en plus du point-virgule. Ca gêne beaucoup l'écriture et lui donne un aspect shell-like qui déplait à beaucoup. Ensuite et surtout de ne pas avoir à l'origine un type de données quelconque qui permet de construire facilement des structures complexes. En Perl, un scalaire peut être une référence quelconque, et les instructions se débrouillent très bien avec. Impossible avec Tcl de base.
Par la suite, l'introduction des namespaces a permis de faire des choses, mais la aussi il y a eut un ratage avec l'obligation d'utiliser les ::. Si le séparateur avait été l'espace, il aurait été facile de faire des objets et instances d'objets qui se comportent comme des références de données complexes, avec un mécanisme intégré au langage, et non pas apporté par une extension (IncrTcl).
Enfin, l'attitude d'Ousterhout a bloqué à mon avis les évolutions surtout de Tk, ce qui a diminué fortement l'intérêt des développeurs d'interface graphique portables. Dommage.
Mais sinon: dès 1996, Tcl/TK supportait Unicode, était complément portable sur Windows, Unix et Mac, il y avait un plugin complet pour Netscape 4, un mécanisme de Thread intégré, de sous-interpréteur avec "sand-boxing" et escalade des privilèges ou équivalents, des extensions objets, .... C'était quand même vachement bien pour l'époque, non ?