Journal connaissez-vous Pike ?

Posté par  .
Étiquettes :
0
11
mar.
2005
[Mavie interest="average" skippable="true"]
Je suis en ce moment à la recherche du "langage idéal" pour mes ptits besoins (développer une appli client/serveur avec une belle interface graphique). Voici un aperçu de mes exigences :
- multiplateforme (au moins linux et ouinouin)
- permettant de créer une interface graphique (donc avec un toolkit multiplateforme aussi, genre GTK ou WxWindow)
- avec accès à une base MySql
- langage orienté objet, de "haut niveau" (exit le C/C++ !), pourquoi pas un langage de script d'ailleurs,
- syntaxe claire (désolé, mais Perl c'est au-dessus de mes forces !)
- raisonnablement rapide (Java, merci d'être passé, à bientôt)
La cerise sur le gâteau serait d'avoir un IDE complet avec création d'interface à la souris et tout et tout.

J'avais 2 candidats bien partis : FreePascal (et son IDE Lazarus, mais pour l'utilisation de MySql c'est la m---e) et PHP/PHP-GTK, super en plus je connais bien le PHP.

Pis voilà qu'au détour d'un coin sombre du net, je tombe sur Pike[1] ("brochet" en Anglais, d'ailleurs j'aime bien le brochet)
[/MaVie]

Pike est un langage de script, compilé en langage intermédiaire à l'exécution, avec une syntaxe proche de Java/C#, disposant de pas mal de modules en standard (Sql, GTK, etc.), existe pour Windows (installeur clicclicclic) et linux (j'ai cru lire quelque part que ce serait même dans les dépots Debian )

Halléluiah !
Pour modérer l'enthousiasme, il faut dire qu'il n'existe pas d'IDE (un fichier de config emacs est parait-il fourni), et y'a pas autant d'utilisateurs de Pike que de PHP ou Python par exemple.


[1] http://pike.ida.liu.se/(...) site officiel

  • # j'y connais mais...

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

    Je suis à la recherche comme toi du langage qui va bien et qui marche de partout. J'essai de me pencher sur le cas C# et .NET, ça à l'air d'être multiplateforme (mono pour linux, et framework SDK pour win), il existe un IDE sharpDevelop pour win, pour linux : monodev (ou un truc du genre). La condition, il me semble, pour que ça marche bien est qu'il ne faut pas utiliser des trucs spécifique à l'os, même si mon prof d'info me soutient que je peux prendre un truc qui sort de l'API win32, compiler sous win et poufff par magie ça marche sous linux. Je reste perplexe.

    Born to Kill EndUser !

    • [^] # Re: j'y connais mais...

      Posté par  . Évalué à 3.

      si ça marche c'est parce que l'équipe de mono a implémenté l'API graphique win32. Le problème est qu'elle est probablement brevetée comme pas croyable, donc soumise au bon vouloir de MS

      De mon coté je me demande si gtk# marche sous win... quelqu'un a déjà essayé ?

      • [^] # Re: j'y connais mais...

        Posté par  . Évalué à 4.

        Le problème est qu'elle est probablement brevetée comme pas croyable, donc soumise au bon vouloir de MS

        Breveter peut être pas (je ne vois rien d'"innovant" dans une API qui puisse justifier l'acceptation d'un brevet). En revanche MS peut en changer n'importe quand et casser la compatibilité. Une réimplémentation des APIs d'un concurrent sera toujours à la traine par rapport à l'original. Ce sera toujours une version dégradée et je ne trouve pas que ça donne une bonne image du libre.

        • [^] # Re: j'y connais mais...

          Posté par  . Évalué à 2.

          oué enfin je vois pas comment ils casseraient leur api pour casser la compatibilité avec mono sans casser la compatibilité avec les produits développés pour la même API sous windows, et ca ferait geuler un paquet de monde ;)

          Le risque c'est surtout qu'ils créent une nouvelle API et que mono ne puisse pas suivre tout de suite, ce qui n'empècherait pas l'ancienne API de fonctionner toujours.

    • [^] # Re: j'y connais mais...

      Posté par  . Évalué à 6.

      J'ai regardé aussi du côté de .net, y'a une IDE toussa mais par contre côté bases de données c'est pas ça (ou j'ai pas bien vu).

      Effectivement ton prof d'info a un peu abusé d'excitants, l'implémentation de Windows.Forms (l'API windows pour l'interface graphique) est loin d'être finie dans Mono. Sur le site ils parlent d'essais en couplant mono et wine, mais faut aimer les montages au chatterton !

  • # Projet en Pike : Caudium

    Posté par  . Évalué à 4.

    Caudium est un serveur web alternatif notamment codé en Pike. Il permet notamment de faire des pages webs dynamique avec du pike. Interessant à regarder pour une alternative à Apache, il a quelques avantages que je vous laisse découvrir sur leur site [1].

    [private]
    En plus c'est des anciens des dinos de l'iteam qui le maintiennent :)
    [/private]

    [1] http://caudium.net/home.html(...)

  • # Pike/Roxen

    Posté par  (Mastodon) . Évalué à 2.

    si jamais je crois que c'est le langage de choix pour le serveur web Roxen :

    http://www.roxen.com/products/webserver/(...)

  • # Perl n'est pas assez clair? O_o

    Posté par  . Évalué à 7.

    Juste pour réagir sur Perl.

    C'est une idée reçue de penser que tout programme Perl n'est pas maintenable ou complétement incompréhensible.
    Perl est un langage très simple qui permet d'en faire ce que tu en veux comme tu le veux. Il est assez permissif mais peut être très strict.
    La syntaxe en elle-même est semblable à n'importe quel langage du genre (PHP,...)

    Je t'encourage a tenter d'écrire quelques lignes avec les pragmas suivant:
    use strict;
    use warnings;

    Tu verras que tes programmes seront clairs.

    • [^] # Re: Perl n'est pas assez clair? O_o

      Posté par  . Évalué à 5.

      Je suis d'accord avec toi, sauf que s'il cherche un langage à peu près objet, Perl n'est surement pas le meilleur choix (tout comme Php). J'ai arrêté d'utiliser Perl le jour ou j'ai commencé à vouloir faire de l'objet avec, ça devient vraiment illisible est ça n'apporte pas beaucoup de fonctionnalité objet. Pour la syntaxe de Perl effectivement il n'a pas grand chose de nouveau à part peut être les regexps mais c'est plutôt à cause des raccourcis permissifs que le code devient illisible (variable magique). Par contre comme tu le fais remarquer c'est au développeur de faire attention à ce qu'il code et de s'efforcer de garder lisible son travail.

      Pour en revenir au sujet du journal, je conseillerais à qstone d'essayer plutôt un langage comme Python ou Ruby (en attendant Perl6 peut être). Python à l'avantage d'être facilement abordable pour les personnes venant du monde procédurale (C, C++ ...) et d'avoir beaucoup de bibliothèques disponibles. Ma préférence va pour Ruby qui est totalement objet (aux structures de contrôles près) et qui permet une liberté d'expression assez formidable (tout en restant lisible à mon avis).

      L'avantage du libre est d'offrir un grand choix de langage dans lesquels on trouve souvent son bonheur.

      • [^] # Re: Perl n'est pas assez clair? O_o

        Posté par  . Évalué à 2.

        Ma préférence va pour Ruby qui est totalement objet

        Python aussi est totalement objet.

        >>> dir(-5)
        ['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__', '__delattr__', '__div__', '__divmod__', '__doc__', '__float__', '__floordiv__', '__getattribute__', '__getnewargs__', '__hash__', '__hex__', '__init__', '__int__', '__invert__', '__long__', '__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__', '__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__']
        >>> (-5).__abs__()
        5

        • [^] # Re: Perl n'est pas assez clair? O_o

          Posté par  . Évalué à 2.

          et ta méthode 'dir' elle est définie dans quelle classe ?

          Comment fais-tu déjà pour accéder à une méthode définie dans une classe mère (le super de Java, Ruby ...) ? super(Class, self).meth(args) ? ben dit donc ça ne fait pas tellement notation objet tout ça !

          Comment fais-tu pour savoir si un objet contient bien une méthode ? hasattr(objet, "methode") ? ça fait pas objet non plus comme notation si ?

          Bref, je ne vais pas refaire la discussion Python VS Ruby mais si ça t'interresse va regarder par là : http://linuxfr.org/comments/517442.html#517442(...)

          Python et Ruby sont des langages de scripts mais la comparaison devrait s'arrêter là, ils n'ont pas du tout la même philosophie. Après qu'on préfére l'un ou l'autre c'est une question de goût, mais de la à dire que Python est totalement objet c'est un peu gros. Je pense que justement c'est une des forces de Python de ne pas être pur objet, ça permet à un plus grand nombre de développeur de s'appropier ce langage sans être perturber (par rapport à Ruby où tu peux par exemple redéfinir la méthode + de Fixnum pour réaliser une soustraction au lieu d'une addition).

          • [^] # Re: Perl n'est pas assez clair? O_o

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


            et ta méthode 'dir' elle est définie dans quelle classe ?


            Les méthodes dir, super, hasattr se trouvents dans le module __builtins__.

            Ce qui ne veut pas dire que python ressemble à l'orienté-objet auquel tu aspires mais bien que tout fait partie d'une classe.

          • [^] # Re: Perl n'est pas assez clair? O_o

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

            Tu parles de surcharge d'opérateurs ? Ben ça existe en Python, avec un garbage collector aussi : http://www.brpreiss.com/books/opus7/html/page596.html(...)

            En Python, tout est supposément un objet, avec, ou pas, propriétés et méthodes inhérantes à cette condition.
            Voir http://www.python.org/doc/current/ref/objects.html(...)

            N'en demeure pas moins que Ruby est un superbe langage.

            Pour répondre à qstone plus particulièrement, peut être que python est une bonne réponse à ses attentes. Glade est un outil pour construire sa GUI en GTK, un petit coup de http://glc.sourceforge.net/(...) pour générer du python avec les bindings qui vont bien, C'est parti !

          • [^] # Re: Perl n'est pas assez clair? O_o

            Posté par  . Évalué à 2.

            Comment fais-tu pour savoir si un objet contient bien une méthode ? hasattr(objet, "methode") ? ça fait pas objet non plus comme notation si ?

            Et alors ? Comment fais-tu pour additionner deux nombres en Ruby ? x + y ?
            Ca fait pas objet non plus comme notation si ? ;)

            • [^] # Re: Perl n'est pas assez clair? O_o

              Posté par  . Évalué à 3.

              Si si, c'est complétement objet en Ruby, + est une méthode de la classe Fixnum prennant en paramètre une autre valeur. Pour s'en convaincre il suffit de taper ceci est de l'exécuter : 
              puts 2+2     # 4
puts 2.+(2)  # 4
              On peut même s'amuser à changer le comportement de la méthode + de Fixnum : 
              class Fixnum
  def +(value)
    self*value
  end
end

puts 2+3    # 6
puts 2.+(3) # 6
              Bref la syntaxe 'x + y' est une forme raccourci de la syntaxe objet 'x.+(y)'.

              • [^] # Re: Perl n'est pas assez clair? O_o

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

                Puis sans compter les len(machin) trop laid. Enfin bon, python était pas fait pour être objet au départ, et ça se voit.

                • [^] # Re: Perl n'est pas assez clair? O_o

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


                  Puis sans compter les len(machin) trop laid


                  En fait, len(machin) c'est exactement comme le + de ruby. C'est une façon simple d'écrire quelquechose qu'on pourrait très bien écrire façon objet : machin.__len__().

                  On aime, on aime pas mais qu'on ne vienne pas dire que ce n'est pas objet parceque c'est aussi faux que de dire que "2 + 3" n'est pas objet en ruby.


                  Enfin bon, python était pas fait pour être objet au départ, et ça se voit.


                  C'est sûre, il y a des "restes", essentiellement c'est la présence des self partout. Mais au niveau OO, il a sacrément bien évolué et est devenu un langage complètement OO.

                  Personnellement, si je devais râler sur quelque chose, ce serait plutôt sur l'ajout des décorateurs qui s'est fait dans la version 2.4. Je n'en conteste pas l'utilité mais je trouve la syntaxe choisie très moche et surtout pas du tout explicite.

                  • [^] # Re: Perl n'est pas assez clair? O_o

                    Posté par  (site web personnel, Mastodon) . Évalué à 2.

                    En fait, len(machin) c'est exactement comme le + de ruby. C'est une façon simple d'écrire quelquechose qu'on pourrait très bien écrire façon objet : machin.__len__().

                    Non, si c'était pareil on pourrait faire un machin.len(), pas un machin.__len__() ... Ca fait une sacrée différence. S'il faut modifier l'analyse syntaxique/lexicale à chaque fois qu'on veut une nouvelle methode sous pretexte qu'on veut un raccourci, on est mal barré tiens...

                    Et j'utilise python, je tente de faire de l'objet avec, mais faut pas pousser mémé, ruby c'est quand même beaucoup plus propre pour ça (et que ça me pousse même à m'y mettre doucement). Le seul truc c'est que actuellement j'ai des besoins de perfs et ruby, c'est pas encore l'extase pour ça.

                    • [^] # Re: Perl n'est pas assez clair? O_o

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


                      S'il faut modifier l'analyse syntaxique/lexicale à chaque fois qu'on veut une nouvelle methode sous pretexte qu'on veut un raccourci, on est mal barré tiens...


                      Donc en ruby, si on définit la méthode 'plus' qui comme son nom l'indique additione deux nombres. On peut faire "x plus y" et on aura "x + y" ? Je l'ignorais, je vais quand même l'essayer parcequ'alors là je serais épaté.

                      Bon j'ai jamais fait de ruby donc soyez indulgents:


                      irb(main):003:0> 5+ 4
                      => 9
                      irb(main):004:0> class Fixnum
                      irb(main):005:1> def plus(value)
                      irb(main):006:2> self + value
                      irb(main):007:2> end
                      irb(main):008:1> end
                      => nil
                      irb(main):009:0> 5.plus(4)
                      => 9
                      irb(main):010:0> 5 plus 4
                      SyntaxError: compile error
                      (irb):10: syntax error
                      5 plus 4
                      ^
                      from (irb):10
                      irb(main):011:0>


                      Il semblerait donc bien certains opérateurs en ruby sont traités différement que s'ils étaient de simples méthodes. Donc l'analyse lexicale est différente pour ceux-ci, donc je revendique à python le droit d'ajouter à cette liste le raccourci len !


                      Et j'utilise python, je tente de faire de l'objet avec, mais faut pas pousser mémé, ruby c'est quand même beaucoup plus propre pour ça (et que ça me pousse même à m'y mettre doucement). Le seul truc c'est que actuellement j'ai des besoins de perfs et ruby, c'est pas encore l'extase pour ça.


                      Goûts, couleurs, tout ça ... Moi par exemple, j'adore python mais je lui préfère quand même le scheme par ce qu'il pousse (c'est un euphémisme) à la programmation fonctionnelle, qu'on peut faire de l'OO avec, que le développement est encore plus rapide avec, mais bon c'est pas demain la veille qu'il sera un standard de l'industrie (malgré le fait qu'il puisse être assez rapide).

                      • [^] # Re: Perl n'est pas assez clair? O_o

                        Posté par  (site web personnel, Mastodon) . Évalué à 2.

                        Tu le fais exprès ou tu n'arrives pas à voir la différence entre un opérateur de base (+ - * etc) et des fonctions telles que len() ou str() ? (str() int() etc en python, non merci...).

                        Pour scheme on s'en fiche, il ne joue pas du tout dans la même cours, alors que ruby et python eux ont plutôt tendance à être au même niveau.

                        • [^] # Re: Perl n'est pas assez clair? O_o

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


                          Tu le fais exprès ou tu n'arrives pas à voir la différence entre un opérateur de base (+ - * etc) et des fonctions telles que len() ou str() ? (str() int() etc en python, non merci...).


                          Ben je dois vraiment être con faut croire. Mais non, je ne vois pas de différence entre (+ - * / etc) et les fonctions len, str, int ... tout ce que tu veux.

                          Pourquoi dans un langage qu'on définit comme full OO, faire de différence entre certaines méthodes ? Ou places tu la barre ? La limite que tu imposes est arbitraire et donc ton argument n'est alors qu'affaire de définition.

                          Et d'ailleurs, ce genre d'argument, on pourrait aisément le transformer en un "Mais tu le fais exprès tu ne vois pas de différences entre les types de base (int str list etc) et les types tels que listes triées, chaine en majuscule, ..." pour justifier le non héritage des types de base (ce qui est mal TM).


                          Pour scheme on s'en fiche, il ne joue pas du tout dans la même cours, alors que ruby et python eux ont plutôt tendance à être au même niveau.


                          Je n'ai mentionné le scheme que pour faire écho à mon "Les goûts, les couleurs", car mon gout est de préférer le scheme qui est effectivement dans une autre cour.

                          Mais finallement dans l'argument, il a quand même sa place car lui sa pureté ne peut pas être prise en défaut. Il y a les literaux et il y a les fonctions. Point barre après tu te débrouilles, pas de fonctions spéciales, pas d'opérateurs particuliers qui méritent un traitement différent, rien ...

                          • [^] # Re: Perl n'est pas assez clair? O_o

                            Posté par  . Évalué à 2.

                            C'est pourtant pas très difficile, il y a 2 cas :
                            - La méthode commence par un symbole non alphanumérique (*, +, -, ', =, %, /, >, < ...) : notation pointée facultative pour permettre une écriture plus conventionnelle des opérations (arithmétiques, booléennes ...)
                            - La méthode commence par un symbole alphanumérique : obligation d'utiliser la notation pointée : 2.plus 3

                            Après pour éviter cette "bidouille" il n'y a qu'un seul moyen propre, c'est de faire comme dans SmallTalk et préférer la notation "objet méthode" à la notation pointée "objet.méthode". Hélas, Ruby devant être compréhensible par un développeur lambda (comme Python) il parait logique d'éviter de perturber ce dernier en lui imposant une syntaxe trop particulière même si cette dernière est finalement plus propre (et surtout plus facile à parser :). C'est dans le même but que dans Ruby les structures de contrôles (if-then-else, while ...) ne sont pas des méthodes des classes True et False.

                            De toute façon, plus j'utilise de langage objet (Java, Eiffel, C++, C#, Python ...), plus je me rends compte qu'ils évoluent de plus en plus vers SmallTalk. Bref, je suis sûr que si demain Microsoft (ou un autre grand éditeur) resortait SmallTalk tout le monde trouverait ça merveilleux. Bref, SmallTalk est sortit 30 ans trop tôt :/.

                            Pour en revenir à Ruby et Python, ça n'est pourtant pas difficile de comprendre la différence de philosophie : un de ces 2 langages a été conçus dès le départ pour être un langage de script objet et l'autre non. Du coup, Python se retrouvent à trainer une compatibilité qui nuit à mon avis à son évolution vers du full OO. Mais d'un autre coté comme je l'ai dit plus haut, c'est surement ce qui a permis à Python d'être autant utilisé à travers le monde aujourd'hui, il a réussi à fédérer les gens vennant du monde procédurale (C...), du scripting (Shell, Perl ...) et du monde objet (Java, C++ ...). Python est le vrai premier langage de script orienté objet à avoir su s'imposer face à Perl. C'est l'étape décisive avant de pouvoir convertir les gens à des langages full OO.

                            Enfin, je ne comprend pas cette levée de bouclier des gens faisant du Python quand on dit que Ruby est beaucoup plus orienté objet que leur langage préféré. Ce n'est pas obligatoirement un mal. Ça me fait pensé à cette époque pas si lontaine où on n'avait pas le droit de critiquer Java en tant que langage objet.

                            Bref, cette discussion commence à me fatiguer ... je vais me coucher :)

                            • [^] # Re: Perl n'est pas assez clair? O_o

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


                              C'est pourtant pas très difficile, il y a 2 cas :
                              - La méthode commence par un symbole non alphanumérique (*, +, -, ', =, %, /, >, < ...) : notation pointée facultative pour permettre une écriture plus conventionnelle des opérations (arithmétiques, booléennes ...)
                              - La méthode commence par un symbole alphanumérique : obligation d'utiliser la notation pointée : 2.plus 3


                              Je sais faire la différence, mais l'astuce c'est qu'elle réside uniquement dans les yeux de celui qui regarde car comme tu le dis plus loin, cette différence est une "bidouille" (tout à fait acceptable et même bienvenue, j'en conviens).

                              Donc pour résumé moins point de vue:

                              - une fonction est une fonction qu'elle s'appelle "+" ou "plus"

                              - pour simplifier la vie des programmeurs il existe des bidouilles (+,-,*, ...)

                              - len en python est une de ces bidouilles.

                              Ce n'est donc pas à ce niveau que python est moins OO que ruby à d'autres pourquoi pas, je ne connais pas assez bien ruby pour en parler. Mais à ce niveau là sûrement pas, puisque conceptuellement ils font la même chose.


                              Enfin, je ne comprend pas cette levée de bouclier des gens faisant du Python quand on dit que Ruby est beaucoup plus orienté objet que leur langage préféré. Ce n'est pas obligatoirement un mal. Ça me fait pensé à cette époque pas si lontaine où on n'avait pas le droit de critiquer Java en tant que langage objet.


                              Tu sais moi que python soit plus ou moins object que ruby je m'en balance, les gens utilisent encore ce qu'ils veulent. Ce qui m'importe dans cette histoire c'est qu'on ne dise pas de trucs qui sont visiblement faussés par un a priori.

            • [^] # Re: Perl n'est pas assez clair? O_o

              Posté par  . Évalué à 3.

              En C++ au moins on peut écrire : x.operator +(y)
              C'est moins lisible mais ça fait bien objet :-)

    • [^] # Re: Perl n'est pas assez clair? O_o

      Posté par  . Évalué à 6.

      Je n'ai pas dit que le Perl n'a pas une syntaxe claire, j'ai dit que c'était au-dessus de mes forces !

      C'est une affaire de goûts, mais plus un langage propose des raccourcis indigestes, moins je l'aime. OK on n'est pas obligé de les utiliser, mais ça veut dire que tôt ou tard on y aura affaire (exemples de code sur le net, etc.).
      J'aime pas le if-then-else raccourci du C (et dérivés) (test ? actionSiVrai : actionSiFaux)

      Du peu de tutoriel Perl que j'ai lu, y'avait déjà trop de $%, $$a et autres $_ à mon goût. J'ai décroché quand j'ai vu qu'on pouvait remplacer les délémiteurs usuels par d'autres (pour définir les chaines caractères, un truc du genre qq!chaine! )
      Je suis d'accord pour dire qu'on peut écrire de bons softs bien propres en Perl, mais personnellement je n'accroche pas.

    • [^] # Re: Perl n'est pas assez clair? O_o

      Posté par  . Évalué à 3.

      C'est une idée reçue de penser que tout programme Perl n'est pas maintenable ou complétement incompréhensible.

      Le gros problème d'un langage permissif qui autorise whatmille astuces de syntaxe c'est que pour maintenir le code d'un autre développeur il faut maitriser toutes les astuces que les autres développeurs ont pu utiliser. Dans une boite on peut imposer des coding rules mais dans le cas de logiciels libres developpés par des équipes différentes, au final il faut connaitre chaque subtilité du langage car sur le nombre de personnes la quasi totalité des possibilités sera utilisée. Plus la langage propose d'astuces et plus c'est le bordel (C++ ?).

      L'autre chose que je reproche à Perl et à plusieurs autres langages c'est cette manie de vouloir optimiser au maximum le nombre le nombre de caractères à taper. Je préfère un code plus expansif qui se lit sans difficulté qu'un truc qui fait la même chose en une ligne et qui demande un grand effort de lecture. Et ça se ressent jusque dans le nommage des variables et méthodes. Là au un perliste ou un C-iste écrirons des "authusr()", en Java, Pascal ou autre on préfèrera appeler la même méthode "getAuthentifiedUser()". C'est plus long à taper mais ça se lit tout seul. Il faut garder à l'esprit qu'en général mis à part pour du code jetable, une même ligne de code sera écrite une fois mais relue des dixaines de fois et ce par moultes personnes différentes. Dans ma boite, on a une grosse appli métier codée en Delphi et même un marketeux ne sachant pas programmer est capable en regardant le code de dire ce que ça fait.

      • [^] # Re: Perl n'est pas assez clair? O_o

        Posté par  . Évalué à 3.

        Avec les pragmas cités, il n'y a plus "whatmille" façons de faire les choses.
        Et pour comprendre un code, on peut y placer des commentaires.

        En ce qui concerne les conventions d'écriture, le problème sera le même avec tous les langages. Ce sont des conventions, chacun fait ce qu'il veut (surtout dans le cas du nommage des variables et des fonctions).

        Je n'omais aucunement les divers problèmes qu'entraine l'utilisation du Perl.
        En l'occurence, ce n'était pas le sujet. On peut trouver des choses à redire à chaque langage, c'est ce qui fait qu'il y en a autant.
        Je me bats contre une idée reçue précise.

  • # Python

    Posté par  . Évalué à 5.

    Je n'ai pas envie de m'étaler en long en large et en travers, mais ma réponse à ta question sera simplement : Python.
    Il fait tout ce que tu dis, et même plus !

  • # Eiffel, Ruby

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

    Bon, je vais moi aussi mettre de mon grain de sel :)
    D'abord, deux langages différents qui répondent à tes critères :
    - Eiffel qui un langage objet de haut niveau, de typage statique, qui supporte la généricité, la covariance, la conception par contrat, l'héritage multiple (finement géré) et qui a une syntaxe simple et claire. Avec l'édition communautaire ou free d'EiffelStudio (http://www.eiffel.com/downloads/)(...) tu as un IDE multi-plate-forme, et bien fournie. Sinon tu as la distribution libre d'Eiffel: SmartEiffel auquel tu dois rajouter des lib extérieures comme Gobo par exemple. Un point supplémentaire à Eiffel : il s'interface facilement avec du C (normal, le compilateur applatit le tout en C de façon transparente).

    - Ruby qui est aussi un langage objet de haut niveau, de typage dynamique , qui supporte l'héritage simple, les closures, ..., et qui a une syntaxe claire. Tu as un plugin pour développer en Ruby avec Eclipse. A la différence de Python, la documentation des lib est claire et tout est vraiment objet (il n'y a pas de fonctions ou procédures qui se baladent tout seules comme ça). Le crédeau de Ruby : prendre plaisir à programmer (être le meilleur ami du pogrammeur).

    • [^] # Re: Eiffel, Ruby

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

      Mon intention n'est pas de lancer un débat Python/Ruby : ce sont sont 2 excellents langages; libres qui plus est. Mais dire que l'un a une syntaxe plus claire que l'autre est vraiment subjectif ; on a des 'self' et '__' d'un côté, des '@' et '@@' de l'autre. Perso je trouve que par exemple la syntaxe 'EXPRESSION if CONDITION' possible en Ruby est vraiment moche et nuit à la clarté du code.

      Pour Eiffel, dont j'ai entendu beaucoup de bien, il me semble avoir lu qu'il y avait quelques incompatibilités génantes entre la version officiellle et la version libre SmartEiffel. Qu'en est-il vraiment ??

      • [^] # Re: Eiffel, Ruby

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

        Relis mon commentaire : je n'ai jamais dis que la syntaxe de Ruby est plus claire que celle de Python. J'ai dis que la documentation des lib est plus claire comparé à Python.

        De plus la syntaxe 'EXPRESSION if CONDITION' vient en fait de Perl et elle n'est pas moche. Elle est même claire lorsque tu la lis (si l'expression est évidemment courte). Par contre que tu ne l'apprécies pas est autre chose, c'est une affaire de goût.

        Sinon, pour Eiffel, il y a effectivement des petites différences chiantes entre les librairies de SmartEiffel et celles officielles (standardisées) qui ne sont en fait que des lib de bases !
        Mais là où ça se gâte est qu'il n'y a pas de standardisation avec les libs souvent utiles pour les dev de tous les jours (par exemple sur les collections/containeurs). Aussi, chaque fournisseur (VisualEiffel, SmartEiffel, etc.) développent chacun à leur façon les libs supplémentaires. Gobo a tenté de fournir une réponse à cette problématique en définissant des librairies pour quelque soit le compilateur Eiffel.
        Le problème avec SmartEiffel est que c'est une distribution pour la recherche et donc elle introduit pas mal d'incompatibilités par rapport à l'"officiel" sachant en plus que Eiffel est en cours de standardisation à l'ECMA et que de nouvelles caractéristiques sont définies. Et chacun l'implémente à sa façon.
        Exemple sur les agents : SmartEiffel l'implémente avec une structure contravariante tandis que VisualEiffel l'implémente avec une structure covariante. Bien sûr, conceptuellement chacun a raison même si la version de SmartEiffel me parait plus ... propre.

    • [^] # Re: Eiffel, Ruby

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

      SmartEiffel c'est par là : http://smarteiffel.loria.fr(...)

      La version 2.1 du compilateur est sortie début février et comprend désormais un support réseau (certes minimaliste) dans l'API standard.

    • [^] # Re: Eiffel, Ruby

      Posté par  . Évalué à 2.

      s/crédeau/credo/ (c'est du latin).

  • # Java ?

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

    - raisonnablement rapide (Java, merci d'être passé, à bientôt)

    On peut connaitre les fondements de ta remarque ? Si ce n'est le vieux mythe de 'Java s'est lent' ?


    regarde un peu http://www.thinlet.com(...)

    • [^] # Re: Java ?

      Posté par  . Évalué à 4.

      Avec plaisir.
      L'outil est destiné à fonctionner sur des ordinateurs pas récents ( 5 ans et plus, donc faut pas s'attendre à avoir énormément de ram), pas forcément entretenus (=pas mal de saloperies au démarrage), etc.

      Dans ce contexte, oui java c'est hyper-lent, au moins à démarrer (charger la jvm etc.) surtout quand il s'agit d'applis graphiques. Il y a très peu d'algos ou de calculs complexes sur lesquels les différences serait moins évidentes.

      J'aime énormément java, je trouve ça très clean, mais quand je dois faire une appli qui doit être déployée sur des machines pauvres en ram, j'hésite.
      J'essaierai thinlet à l'occasion, je ne connaissais pas (j'ai surtout utilisé AWT)

    • [^] # Re: Java ?

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

      Je développe couramment en Java dans mon boulot depuis plusieurs années et je dis ceci :
      oui Java est peu performant en consommation mémoire (surtoût) et CPU (dépend de l'appli et de la JVM).
      Dire que Java est lent n'est pas un mythe c'est une réalité mais cela vient principalement de la JVM. Par exemple, une JVM d'IBM te produira des performances qui peuvent remettre en cause l'assertion "Java est lent".
      Par contre la force de Java est donné par son but : "write once, run everywhere", par sa syntaxe simple et compréhensible par bcp de monde (parce que dérivé du C), et de s'appuyer sur des conceptions à peu près compréhensibles par bcp.

  • # en conclusion...

    Posté par  . Évalué à 1.

    Bon bah pour en revenir au titre de mon journal, non y'a pas grand'monde qui connaît Pike (notez que je me sens moins bête d'avoir découvert ça il y a 3 jours seulement, c'est déjà ça)

    Pour la petite histoire, je vais donc certainement développer mon appli avec Pike, sa syntaxe et sa logique me vont très bien :o) J'avais pas vu si bien depuis Java (couché le Troll, couché ! C'est une appréciation personnelle ici !)

    Si jamais j'ai donné des idées à certains, sachez que le mieux (que j'aie trouvé à ce jour) pour éditer du Pike c'est jEdit (ok y'a Emacs, m'enfin...bon... Oh et puis j'en ai marre des trolls !).

    http://www.jedit.org site de jEdit
    http://www.update.uu.se/~peterl/html/sub_hobbies/comp/articles/jEdit/ l'article de Peter Lundqvist sur l'utilisation de jEdit pour Pike

    En bonus gratuit supplémentaire : quelques plugins pour jEdit à ne pas rater :
    - ProjectViewer : pour gérer un projet
    - BufferTabs : afficher les fichiers ouverts sous forme d'onglets (cf. photos d'écran de Peter Lundqvist)
    - Console : pour exécuter vos fichiers sans quitter jEdit
    - ErrorList : pour récupérer les messages d'erreur de la console comme tout IDE qui se respecte

  • # Ferite

    Posté par  . Évalué à 1.

    Ferite est un petit frere de Pike et merite a mon avis qu'on y jete un oeil ...

    • [^] # Re: Ferite

      Posté par  . Évalué à 1.

      Il est mignon aussi (d'ailleurs j'ai pas trouvé le lien entre ferite et pike, il y en a un ?).
      Par contre dès qu'on part vers ces langages, la documentation fait cruellement défaut. Pike ça va, mais il parait que c'est loin d'être à jour, Ferite c'est assez succint, freepascal et lazarus c'est pas la joie non plus... Dommage !

      • [^] # Re: Ferite

        Posté par  . Évalué à 1.

        non pas de lien direct, si ce n'est d'avoir une syntaxe proche du C, mais des concepts de plus haut niveau.

        Ferite est le petit frere dans le sens ou il semble moins aboutit. Voila ce que je voulais dire.

  • # Capitaine Pike

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

    Pike était le capitaine qui à précédé le capitaine Kirk à la tête de l'Enterprise (Star Trek). On peut le voir dans l'épisode 0 "La Cage", dans lequel joue la première équipe d'acteurs, parmi lesquels figurait déjà Leonard Nimoy (Spock). Cet épisode à été inclus dans les épisodes 11 et 12 de la première saison des séries originales ("La ménagerie" 1ere et 2eme partie)

    Il est amusant de penser qu'en France, cette série n'a jamais percé (ou plutôt ces séries, car durant ces 40 dernières années il y a 5 séries basée sur cet univers, 10 longs-métrages, et des dessins animés) . Au contraire, elle a été dépréciée à tel point qu'il était ridicule ne serait-ce que de la conaître. Mais une fois la frontière passée, cette ségrégation tombe.

    Malheureusement, un univers aussi riche, complet et prolifique que celui de Star Trek devrait être sous licence libre ;) Mais cet univers est protégé par la paramount, qui ne compte certainement pas le lâcher comme ça.

Suivre le flux des commentaires

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