Conférence EuroTcl 2010

Posté par  . Modéré par Florent Zara.
Étiquettes :
5
13
mai
2010
Communauté
La 9ème édition de la Conférence Européenne des Utilisateurs de Tcl/Tk aura lieu le 4 et le 5 juin 2010 à l'IGBMC près de Strasbourg.

Depuis 10 ans, une conférence européenne est organisée chaque année (sauf 2004) afin de permettre aux utilisateurs (professionnels et amateurs) et aux personnes impliquées dans le développement du langage de script Tcl/Tk de partager leurs expériences et de présenter leurs réalisations.

Vous pouvez vous inscrire et soumettre les résumés de vos présentations. La limite de soumission est fixée au 21 mai 2010.

Aller plus loin

  • # Quel est l'avenir de tcl/tk ?

    Posté par  (site web personnel) . Évalué à 3.

    Il y a quelques années, j'avais beaucoup apprécié Tcl/Tk en raison de sa portabilité sur HP-UX qui me permettait de mettre au point le programme sous Linux.

    Je m'interroge quant à son avenir. Malgré quelques brillantes réalisations, je trouve Tcl/Tk un peu dépassé par d'autres langages. Est-ce que ce n'est qu'une impression ? Vos avis m'intéressent.
    • [^] # Re: Quel est l'avenir de tcl/tk ?

      Posté par  . Évalué à 0.

      le même que Mandriva. "irrelevant".
    • [^] # Re: Quel est l'avenir de tcl/tk ?

      Posté par  . Évalué à 4.

      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  (site web personnel) . Évalué à 2.

        J'aime bien Tcl, justement pour la simplicité de sa grammaire.
        Et pour la version 8.6 (que j'attend avec impatience) on a droit aux objets, intégrés dans le language, nativement.

        Par exemple:


        oo::class create fruit {
        variable color
        constructor {{c ""}} {
        set color $c
        }
        method get_color {} {
        return $color
        }
        }

        oo::class create orange {
        constructor {taille} {
        next orange
        }
        }

        set mon_orange [orange new 5cm]
        puts [$mon_orange get_color] ;# --> "orange"
    • [^] # Re: Quel est l'avenir de tcl/tk ?

      Posté par  . Évalué à 2.

      Pareil: ça fait longtemps que l'interet majeur de Tcl/Tk était Tk du fait de sa portabilité, Tcl ayant été supplanté par d'autre langage (d'ailleurs Tk maintenant en face de Qt, bof..).

      Historiquement c'était d'abord Perl mais je pense que l'avenir c'est plutôt Python ou Ruby: plus j'ai utilisé le langage Perl, moins je l'aime (et quasiment tout les autres développeurs que je connais qui utilisent Perl sont de cet avis).
  • # [^]Re: Quel est l'avenir de tcl/tk ?

    Posté par  . Évalué à 2.

    Tcl-Tk a encore de l'avenir !

    Mais cela reste un marché de niche.
    A ma connaissance, il est surtout utilisé pour des développements en interne dans l'industrie. Grâce à sa facilité d'apprentissage et au couplage natif avec une IHM.

    Au fil des années, Tcl-Tk conserve quelques qualités:

    - Stabilité: un code écrit il y a 10 ans fonctionne encore aujourd'hui.
    - Portabilité: sur les unices, Windows et Mac OS comme pour les autres langages de script. Avec en plus Windows Mobile, Androïd (eTcl - [http://www.evolane.com/software/etcl/]) et une version (Hecl - [http://www.hecl.org/]) pour
    les mobiles qui supportent J2ME.
    - Facilité d'apprentissage: comme l'a très bien souligné Joël, cela donne accès pour des non-informaticiens à un langage de programmation facile à apprendre avec, en bonus, une IHM facilement programmable. Beaucoup d'ingénieurs pragmatiques se moquent pas de l'esthétisme de leurs IHM. Je ne suis pas certain qu'un ingénieur qui passe 90% de son temps à faire autre chose que de l'informatique ait envie de se lancer dans une programmation d'IHM complexes.
    - Déploiement: le système "Starkit ([http://wfr.tcl.tk/46]), une sorte de système de fichiers virtuel permettant de regrouper dans un seul fichier tous les éléments d'une application Tcl-Tk. Ce qui inclut les codes sources, les images, les bibliothèques partagées ou les extensions. Ce fichier .kit peut-être exécuté sur n’importe quelle plate-forme, sans y apporter la moindre modification. Le système (Starpack - [http://wfr.tcl.tk/46]) qui permet de créer un runtime exécutable. Donc nul besoin d'installer un interpréteur Tcl-Tk. L'installation consiste à copier un fichier et la désinstallation à l'effacer.
    - Aspect: le manque d'esthétisme de Tk a longtemps été décrié. Aujourd'hui, les applications Tcl-Tk sont thémables. Voilà à quoi ressemble une application Tcl-Tk maintenant: [http://wiki.tcl.tk/13636]
    - Interaction avec le langage C: à plusieurs niveaux. Bas niveau en écrivant des extensions pour Tcl-Tk. Haut niveau: en embarquant du code C compilé à la volée dans Tcl grâce à l'extension CriTcl ([http://wfr.tcl.tk/992]) ou Odyce ([http://www.evolane.com/software/odyce]).

    Le plus grand point faible de Tcl-Tk est sans nul doute la promotion et la communication.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.