ruby ou python

C'est même une erreur de syntaxe explicite. Du reste, les conventions de codage (la PEP-08 en particulier) sont justement faites pour que personne n'ait jamais besoin de ré-indenter son code.

Ces deux éléments ne son pas aberrants à mes yeux. Au contraire ils règlent intrinsèquement des problèmes qui m'ont pourri la vie pendant des années sur des codes Perl ou C au boulot… dans l'industrie, justement.

Tu pourrais développer ce point ? Il me semble plutôt que le fait que le développement de Python tourne autour d'un BDFL est une mesure visant à garder en tout instant un langage homogène. En fait, je ne vois pas du tout ce qui te fait dire ça.

Le fait que le fonctionnel est selon vos propres termes mal intégré/ajouté. On sent aussi une surcouche pour les objets. En ruby, on a vraiment tout qui est objet (comme signalé – ce qui permet des trucs très bizarres comme l'ajout de méthodes à des instances (je n'ai pas dit type)). J'aime aussi beaucoup la fonctionnalité d'import de code (qui est complémentaire à celle d'héritage) en ruby. Cela donne l'impression d'un langage pondu par un théoricien/académicien. Python me donne une sensation de langage pragmatique où des choses ont été rajoutées au fur et à mesure.

Pour la ré-indentation, ce besoin est permanent dans tout code. Il suffit d'une fonction qui ne respecte pas le SRP (chose que l'on voudrait corriger), ou qui se voit conférer plus de responsabilités que ce quelle en avait au départ, et on se retrouve à déplacer des blocs de code. Ou même un algo que l'on avait mal conçu (/écrit lors du premier jet). On réorganise des trucs dedans et pouf des blocs bougent. Or, des blocs qui bougent, il faut les remettre à leur place (lire profondeur d'indentation). L'autre exemple que j'ai pris : c'est l'ajout de code trouvé sur internet. Personne ne me fera croire que tous les codeurs pythons sont perfectionnistes, voire qu'ils écrivent tout d'eux-même. Les codeurs de passage ou qui ne maitrisent pas tout et qui intègrent des briques trouvées à droite/à gauche sont nombreux. Avec l'indentation sémantique, l'intégration est plus complexe qu'avec des délimiteurs de blocs.

Certes il existe des règles qualité, mais franchement, on sait tous comment elles sont appliquées. Dans chaque boite il y en a une poignée comme nous qui se force à les respecter, des fois on passe pour des casse-noisettes, voire même on écrit des notes/règles à destinations des projets et cie. Et pourtant … le SRP est la règle qui doit le plus souffrir en industrie.

@lmghs : on sent une surcouche pour les objets ? Really ? T'as pas dû faire beaucoup de Python, si tu dis ça. Ton premier paragraphe ne fait que dresser une liste de similitudes rigoureuses entre Python et Ruby (si j'en crois ce que tu dis sur Ruby, hein, je ne connais pas ce langage). En Python, tout est objet. C'est la base du langage. Même les classes sont des objets, ce qui permet de faire des trucs très marrants en construisant un classe sur une autre méta-classe que celle par défaut, par exemple. Et l'import, depuis Python 3, est très bien géré, logique et cohérent.

Je ne me lancerai pas dans le débat sur l'indentation, par contre, il me semble stérile.

@Kje et nohar : statistiquement, il est vrai que la transition est majoritairement déjà derrière nous, et la plupart du temps c'est agréable. Cependant, il reste des trous, des besoins de programmation pour lesquels aucune lib native Python 3 ou portée par ses concepteurs n'existe. Pour l'exemple, c'était le cas il y a deux ans de la spatialisation sonore (un peu moins maintenant, sans trop fouiller je suis tombé récemment sur pySFML qui fonctionne maintenant en Python 3, avec SFML 2.0 ; il y a deux ans on était limité à SFML 1.6 et Python 2.6 ou 7, je crois), et c'est encore le cas du TTS. Je mets au défi quiconque sur ce thread de me donner un moyen de faire du TTS en Python 3, sous Windows, clés en main. Cela n'existe pas, et les libs qu'on peut trouver sur Internet sont soit obsolètes, soit réservées à Linux, soit non portées sous Python 3.

Donc nohar, y'a encore des points de frottement. Après, je suis conscient que c'est sans doute uniquement sur des besoins techniques précis et peu répandus, et je grinche, je grinche (oui, ça existe ) mais c'est pour la forme : en réalité, vous avez raison, la transition est presque entièrement effectuée et pour le peu qui reste, on peut toujours se démerder, mettre les mains dans une lib pour la traduire, etc.

Edit : juste un truc à propos du fonctionnel… La plupart des langages impératifs autorisent dans une certaine mesure la programmation fonctionnelle (à petite dose), et l'inverse est aussi vrai. Mais demander à un langage impératif de l'intégrer de manière optimale, c'est absurde ; les deux paradigmes sont presque diamétralement opposés, et rares, très rares sont les langages impératifs qui disposent d'une pile de récursion optimisée. Est-ce que c'est vraiment une critique qu'on peut adresser à Python ? Je ne pense pas. Est-ce que Ruby permet le fonctionnel ? Plus efficacement que Python ?… J'en sais rien du tout.

Je mets au défi quiconque sur ce thread de me donner un moyen de faire du TTS en Python 3, sous Windows, clés en main. Cela n'existe pas, et les libs qu'on peut trouver sur Internet sont soit obsolètes, soit réservées à Linux, soit non portées sous Python 3.

espeak fonctionne très bien sous windows et linux, non ? Donc ça doit pas être bien dur. Et à supposer que tu ne veuille pas faire des appels direct, il semble déjà y avoir quelques wrapper ici ou là. Alors certes ils sont peu mis a jour, mais tant que eSpeak ne casse pas son interface, il n'y a pas de raison de mettre a jour quoique ce soit.

On sent aussi une surcouche pour les objets.

Le bloc de données (la structure, le lego) élémentaire est l'objet en Python (i.e. la structure C PyObject dans l'interpréteur). On peut difficilement considérer que c'est une surcouche, dans ces conditions.

Je comprends ton point de vue pour la ré-indentation. Dans ce cas, il suffit de se rappeler les touches < et > dans Vim, qui font parfaitement le job. Certes, c'est pas aussi puissant qu'un gg=G, mais très honnêtement, ça ne m'a jamais gêné en 8 ans.

Quant au fonctionnel, je ne pense pas qu'il ait été ajouté mais mal intégré. Le fait que les fonctions soient des objets à part entière permet (et c'est même une partie importante du langage) de créer et d'utiliser des fonctions d'ordre supérieur (c'est notamment le cas des décorateurs, pinacle du "pythonisme"), et autorise l'utilisation naturelle de constructions qu'on retrouve dans les langages fonctionnels (de façon non-exhaustive, les list/tuple comprehensions, generator expressions, map et reduce). Néanmoins ce n'est pas à voir comme "une intégration du paradigme fonctionnel dans Python", puisque le Guido Van Rossum lui-même décourage l'utilisation de fonctions récursives, justement pour éviter de casser l'homogénéité du langage et de violer la règle "There should be one, and preferably only one, obvious way to do it".

Je pense que ce serait une erreur que de croire à une volonté d'intégrer le paradigme fonctionnel dans un langage dont la moëlle est orientée objet.

PS : Notamment parce qu'il est à mes yeux illusoire de vouloir intégrer ce paradigme sans le typage qui va avec.

1
2
3
4

RubyVM::InstructionSequence.compile_option = {
  :tailcall_optimization => true,
  :trace_instruction => false,
}

Apparemment oui, il y a une optimisation sur la récursivité, elle n'est juste pas activée par défaut. Selon un bench, ça permettrait d'avoir du code récursif aussi rapide que du code impératif. Mais par exemple, JRuby ne fonctionne pas avec.

@Kje : yep, c'est pas dur si tu as la foi de décrypter la lib fournie avec et d'en faire un binding via ctypes (parce que piège ! la plupart des trucs qu'on trouve sur internet pour utiliser eSpeak avec Python ne sont pas des bindings, mais des trucs de sauvage qui passent par des subprocess et espeak-console, comme ton premier lien : non seulement c'est assez moche, mais en plus c'est pas optimal du tout, hyper lent, bref ça répond pas à ce que je recherchais). Pour ce qui est de python-espeak, j'ai même pas réussi à l'installer chez moi, ça compile pas, ça me donne une erreur incompréhensible et c'est pas documenté.

Pour info la solution que j'ai trouvée s'appelle SteelTTS, dedans y'a un wrapper eSpeak immonde mais aussi un petit script aux oignons qui utilise SAPI (et qui répond exactement à mes besoins). Mais j'ai quand même dû traduire cette lib en Python 3, même si ç'a été facile.

@GaaH : sans vouloir m'avancer, ça m'a tout l'air d'être une "simple" surcouche d'optimisation, pas quelque chose de natif au langage (bon, c'est certes un truc qu'a Ruby et pas Python ). Ça ne fait que confirmer ce que je voulais dire, à savoir que demander à un langage impératif de gérer parfaitement le récursif, c'est lui demander d'être récursif, et c'est idiot.

Via ctypes, peut-être pas, mais en utilisant Cython, c'est vraiment facile et surtout, c'est propre.

Note pour plus tard: écrire un tuto Cython une fois qu'on en aura fini avec le tuto Python.

En fait j'en sais trop rien, tu peux compiler ruby avec ces options, donc j'imagine que c'est quand même "natif". Mais bon, j'ai fais deux trois test, et je vois pas trop la différence … Je me suis pas vraiment documenté la dessus, puisque ça ne m'a jamais posé problème.

Un tuto Cython ? Je suis preneur.

@GaaH : c'est natif dans le sens où c'est intégré au langage, mais pas natif dans le sens où le langage a besoin de cette optimisation artificielle pour compiler "correctement" un code récursif… Je m'exprime mal, désolé.

En fait en python c'est possible aussi avec des décorateurs sans trop de difficultés. C'est pas intégré de base car techniquement ça peut casser du code. En effet la résolution de fonction, en particulier au dernier appel, est censé être fait a l'exécution et donc pourrait être redéfinit :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

def f(n):
    if n==0:
        return 0
    else:
        return f(n-1)

f(5) # ici f fait des appels récursifs optimales

g = f

f = lambda n: 1

g(5)    # renvoi 1 sans appel récursif

Du coup c'est pas intégré

Ouais donc pareil qu'en Ruby, c'est possible avec du scotch, mais c'est pas fait pour.

(J'avais jamais pensé à utiliser les décorateurs pour faire du récursif, ça fait un bon exo pour ce soir, tiens. )

Je t'invite à écrire un compilateur pour un langage quelconque pour te rendre compte de l'inexactitude de cette déclaration.

Un langage de programmation, c'est au minimum :

• un vocabulaire, • une syntaxe, • un modèle de données (comprenant le système de types), • un modèle d'évaluation.

Je me suis peut-être mal exprimé et je m'en excuse, en même temps je ne vois pas comment j'aurais pu faire mieux, mais je ne parlais pas d'un langage de programmation dans le sens général qui inclut tout l'environnement qui va avec. Quand on parle couramment d'un langage de programmation, on a la partie visible, le langage dans le sens syntaxe pure, et ce qu'il y a derrière, l'interpréteur/compilateur, et puis l'environnement et tout le bordel.

J'aurais dû essayer d'être plus clair: ce n'est pas l'ensemble de python que j'exècre, mais uniquement sa syntaxe avec les indentations obligatoires. Pour le relativement peu de fois que je l'ai utilisé par rapport à d'autres langages, sa façon d'aborder les concepts de POO et de fonctionnel qu'il propose derrière ne me paraissent pas si mal conçus face àla concurrence.

J'avais essayé en son temps pour palier à ça de faire un convertisseur de pseudo-python qui utiliserait des blocs {} classiques. J'ai fait mumuse un moment avec des regex et j'ai arrêté parce que ça ne marchait pas bien, les dictionnaires foutaient le bronx.

J'estime simplement que ce n'est pas mon job d'indenter correctement mon code au fur et à mesure, et de devoir réfléchir pour le faire. IL y a des logiciels qui le font automatiquement et très bien, et que ça soit au fur et à mesure de l'écriture, ou pour récupérer du code plus ou moins crado venant du net. Par exemple dans eclipse il y a un raccourci infaillible, et c'est le cas dans à peu près n'importe quel IDE.

Tiens, petite question con pour les IDE python: comment ils font pour identer automatiquement au fur et à mesure ? un IDE pour un langage à accolades en gros résumé c'est facile: tu tapes { enter et on sait que la prochaîne ligne doit être indentée; on tape } enter et pareil, on sait qu'on doit désindenter. Pour python, on tape deux-points enter et on peut indenter, mais pour désindenter on fait quoi ? Désolé pour mon ignorance, je n'ai jamais utilisé d'IDE python.

Mais bon, je crois qu'on ferait mieux d'arrêter ce sous-débat sur l'indentation imposée de python, on a tous l'air d'avoir chacun des opinions bien trempés et de ne pas vouloir en changer de sitôt.

le Guido Van Rossum lui-même décourage l'utilisation de fonctions récursives, justement pour éviter de casser l'homogénéité du langage et de violer la règle "There should be one, and preferably only one, obvious way to do it".

C'est amusant de voir que les philosophies de ruby et python sont en fait totalement opposées sur ce point, ruby ayant une part d'héritage de perl et donc de « there is more than one way to do it ».

C'est amusant de voir que les philosophies de ruby et python sont en fait totalement opposées sur ce point, ruby ayant une part d'héritage de perl et donc de « there is more than one way to do it ».

Ça, c'est aussi un détail que j'apprécie en Python.

J'ai bossé pendant 3 ans avec Perl, et le fait que ça ne soit pas un langage aux idiomatismes bien cadrés lui a valu au bureau la devise "There is more than one way to do it wrong". Chaque fois qu'un collègue vient nous demander comment faire un truc précis en Perl, ça finit presque toujours en concours de la solution la plus dégueu tout en restant efficace.

Et ça se répercute sur notre codebase. On dit souvent pour plaisanter que "Perl est un langage en lecture seule". Même si c'est un cheap troll, cette phrase a sa part de vérité. Il suffit de lire un bout de code maintenu par un autre dev ou auquel on n'a pas touché depuis des mois pour se rendre compte que le fait qu'il y ait systématiquement 15 solutions complètement différentes au même problème est un handicap. On est obligé de réfléchir pour comprendre ce qu'a voulu faire l'auteur du code.

A contrario avec la philosophie inverse, le code devient aussi évident à lire qu'à écrire. C'est une des règles de base du credo de Python : en général, on n'écrit son code qu'une seule fois, mais on n'a aucune idée du nombre de fois qu'il sera relu par d'autres.

@Alkareth : le décorateur doit te permettre d'indiquer que cette fonction mérite d'être optimisé. L'implémentation de l'optimisation peut alors se faire dedans, en général en manipulant le byte code pour plus d'efficacité

L'autre prob qui a toujours rebuter Guido à implémenter ce genre d'optimisation c'est que ça bousille la backtrace en cas d'exception.

@QuentinC : mon IDE sait qu'il doit désindenter quand je tape sur la touche de suppression du caractère précédent. Il vire la précédente tabulation et est donc sortie du bloc. Au final ça fait pas plus de touches tapé que d'accolade.

D'ailleurs mon IDE est aussi assez intelligent pour correctement coller du code provenant du net.

J'estime simplement que ce n'est pas mon job d'indenter correctement mon code au fur et à mesure, et de devoir réfléchir pour le faire

Pas besoin de réfléchir pour indenter ton code tu le fais de toi même naturellement, mais comme tu le dis un peu plus haut

Pour le relativement peu de fois que je l'ai utilisé par rapport à d'autres langages

Tout est dit, ça fait 7 ans que je fais du python, et en 7 ans pas une seule fois je me suis posé ces questions d'indentation.

Quand j'ai attaqué le C, je ne pouvais pas m'empêcher d'indenter, car je trouvais dégueulasse de laisser mon code justifié sur la gauche, et surtout ça le rendait illisible.

pour récupérer du code plus ou moins crado venant du net

Ah ça ! Je ne récupère pas de code venant du net, je ne sais donc pas ce que c'est, en général je prend mon interpréteur et assimile la lecture du code à tester pour que ça tienne en une seule ligne, mais comme je l'ai déjà dis, je parle couramment python, et c'est devenu naturel.

J'avais essayé en son temps pour palier à ça de faire un convertisseur de pseudo-python qui utiliserait des blocs {} classiques

Mon dieu, sacrilège

Tiens, petite question con pour les IDE python: comment ils font pour identer automatiquement au fur et à mesure ? un IDE pour un langage à accolades en gros résumé c'est facile: tu tapes { enter et on sait que la prochaîne ligne doit être indentée; on tape } enter et pareil, on sait qu'on doit désindenter. Pour python, on tape deux-points enter et on peut indenter, mais pour désindenter on fait quoi ? Désolé pour mon ignorance, je n'ai jamais utilisé d'IDE python.

Eh bien je ne peux que te conseiller d'en utiliser un Les limites de bloc sont appelées par la syntaxe ':', l'indentation se faisant automatiquement dans un IDE de la même manière que les accolades pour le C/C++/Java/…

Pour désindenter, j'appuie sur la touche <-

Pour désindenter, j'appuie sur la touche <-

Idem.

Sauf après un return ou un pass auquel cas Vim désindente automatiquement.

Petite question : où est passé l'OP ?

A-t-il fait son choix ?

Y'a une partie de sa question qui m'intéressait et sur laquelle un peu tout le monde (à part brièvement atragis) a passé, c'est dommage.

C'est dans quel domaine il vaudrait mieux choisir RoR que Django et vice-versa.

Notamment l'approche MVT vs. Contrôleur/Vue même si la limite m'a l'air relativement mince et semble parfois se cantonner à de la nomenclature (Vue de RoR = Template de Django, Contrôleur de RoR = View de Django) ça m'aurait vraiment intéressé de connaître des retours de personnes ayant perçu des différences sensibles entre les deux frameworks (autant sur le plan de la conception que des outils etc.) pour en ressortir une comparaison du style "RoR est bien pour", "Django est bien pour".

Pour le reste de la discussion au-delà des discussions sur l'indentation c'était intéressant

EDIT : par exemple, le fait d'avoir des décorateurs est particulièrement intéressant dans un framework web je trouve, firm1 nous l'a montré avec son audit de performances. C'est possible en Ruby également si j'ai bien lu. C'est par exemple un peu plus difficile à faire en Java : il faut passer soit par des outils d'instrumentation de bytecode, soit définir ses propres annotations et utiliser l'APT, soit passer par une bibliothèque d'AOP (mais c'est un peu "gommé" par le fait que plein plein de gens se sont déjà posés la question et ont mis en place tout plein d'outils très bien). Ca fait partie de petits outils du langage dont on peut suligner l'aspect pratique quand il s'agit de concevoir une plateforme (un site) sur le web.

Le problème est qu'il ne doit pas y avoir des tonnes de gens ayants de réels expérience sérieuses dans les deux simultanément et d'avoir un avis exempts d'a priori d'un coté ou de l'autre.

EDIT : par exemple, le […] C'est par exemple un peu plus difficile à faire en Java : il faut passer soit par des outils d'instrumentation de bytecode, soit définir ses propres annotations et utiliser l'APT, soit passer par une bibliothèque d'AOP ([…]

Les serveurs web en java, j'ai l'impression que c'est à peu près tous des usines à gaz par rapport à RoR, si on compte le JSP et tout ce qui va avec. Je n'ai jamais utilisé concrètement donc peut-être que je me trompe, mais c'est l'impression que ça me donne quand on va voir tout ce qu'il y a dedans, même juste un tomcat.

Ce que j'avais trouvé cool quand j'avais voulu testé RoR, c'est qu'on n'avais presque pas de configuration à faire si on définissait ses classes/méthodes/etc. selon un schéma préétabli.

IL y a deux trucs qui m'ont fait arrêter ruby assez tôt dans mon apprentissage en fait.

1° A l'époque je n'étais pas sur serveur dédié donc côté hébergement concret, impossible d'avoir autre chose que php à un prix abordable. Pour le coup, j'imagine que pour avoir python, c'est à peu près pareil. Ca a l'air de rien, mais si on fait un splendide site web mais qu'au final on ne peut pas le mettre en ligne....... bof… on a appris quelque chose mais pour quoi faire ?

2° Ca a peut-être changé maintenant, mais à un moment donné j'avais envie d'essayer de coder un truc rien à voir avec du web, et j'étais tombé sur un truc insoluble et totalement illogique/incohérent: un read sur un socket mettait en attente la totalité des threads de l'application. Ca m'avait complètement bloqué, je me suis dit que ruby c'était drôlement nul si on ne pouvait même pas faire ça. J'ose espérer qu'ils ont résolu çadepuis.