Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Non, mais j'ai une taille d'écran limité (24 pouces) et une mémoire encore plus faillible. J'aime avoir ma boucle entièrement sous les yeux. Je vois pas l'utilité de laisser 3-4 lignes blanches tous les "i++". Compacter le code est parfois une nécessité pour la lisibilité. Mais Python le permet. Il existe le point virgule en Python pour mettre 2 ligne sur une seul. Il est simplement pas obligatoire en fin de ligne.Envoyé par Bktero
Salut,
Bon un nouveau langage de plus... Je ne suis pas trop convaincu de l'intérêt de la chose. Il va falloir finaliser le langage, écrire les bibliothèques, créer l'écosystème et par là même dissiper des développeurs concentrés sur d'autres sujets ... Mon avis est qu'il aurait sans doute mieux valu optimiser un langage existant (comme Python puisqu'il est cité).
En outre, le monde des langages de programmation est déjà bien encombré. Pour le compilateur, l'annonce indique que l'environnement produit du langage C facile à comprendre, tant mieux cela apporte de la portabilité mais la lisibilité du code produit n'est pas un avantage significatif.
Enfin, introduire une syntaxe exotique risque d'être un inconvénient pour son adoption.
@foetus: l'indentation obligatoire de Python poursuit deux objectifs:
- forcer une présentation standard et rigoureuse du code,
- alléger la syntaxe en se débarrassant des symboles de début et fin de bloc d'instruction ({ et }, begin et end...)
Perso, cela ne m'a jamais dérangé même si je n'ai pas une très grande expérience de Python. Je trouve ton analogie rigolote mais mal fondée, ne pas mettre de porte serait un manque fonctionnel et non une simple contrainte (bien qu'on puisse se le permettre sur certaines voitures de course).
Cdlt
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Pas convaincu non plus mais pas pour les mêmes raisons. Une seule en fait : c'est quoi l'intérêt ? Je ne trouve pas plus de détails, à part que c'est fait par un «entrepreneur-consultant» et des étudiants.
Enfin, introduire une syntaxe exotique risque d'être un inconvénient pour son adoption.C'est quoi une syntaxe exotique ? C'est quoi une syntaxe tordue (inutilement) ?(sans parler de la syntaxe un peu tordu inutilement a mon gout, cela va faire fuir les utilisateurs)
C'est quand c'est pas du Java ou du C ? C'est quand on comprend pas ?
Ça me fait penser à Nim (anciennement Nimrod) qui a des objectifs similaires :
"Native code generation (currently via compilation to C), not dependent on a virtual machine: Nim produces small executables without dependencies for easy redistribution."
"Modern type system with local type inference, tuples, variants, generics, etc."
"Statements are grouped by indentation but can span multiple lines."
Etc.
Sauf que Nim a une syntaxe... moins exotique.
@maske
J'apprécie les syntaxes "classiques" à la java, python par la force de l'habitude, des expressions du type:
sont certes originales mais n'apportent pas grand chose, la rupture de forme (le for suit la variable) n'a pas, à mon sens, une grande utilité et peut augmenter inutilement le temps d'assimilation de la syntaxe et possiblement décourager son adoption.
Code ritchie : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6Integer : factorial Integer n result = 1 i for 1,n+1 result = result * i -> result
Enfin, je suis contre la profusion des langages de programmation qui ne font que dissiper les développeurs, je pense qu'il vaut mieux renforcer les outils existants. Mais si le langage apporte réellement quelque chose de nouveau et d'utile ou qu'il se rapporte à un domaine spécifique alors je ne conteste pas.
Cdlt
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Sommes nous d'accord pour dire que justifier quelque chose par l'habitude c'est tout sauf un argument ? =)
En outre, il n'est pas plus facile de maîtriser la syntaxe du java que celle du Caml par exemple. Tout repose sur la fainéantise des développeurs. Donc «syntaxe exotique» = définir pourquoi ou abandonner l'argument.
C'est peut-être fait pour permettre la redéfinition d'éléments syntaxiques qui sont fixes dans d'autres langages. Le problème c'est qu'en fait on sait pas. Pas de doc. Pas de publications sur le langage.
Après le code est extrêmement simple à comprendre sur ces petits exemples, et pas du tout moins simple qu'un exemple en C ou en Python.
C'est à dire ?
Affirmation gratuite. Évidemment, ça ne va pas encourager les feignasses et les débiles. Mais sinon ça ne repose sur rien.
Alors techniquement, ça ressemble de loin à un DSL - donc un outil. Sinon je ne comprend pas le sens de ta phrase. Tu dis qu'il vaut mieux éviter de réfléchir à trop de choses pour se concentrer sur nos acquis ?
Je suis d'accord. Là ça ressemble à un exercice de style (et bon bof...).
Un IDE permet de régénérer une indentation. (ça a des limites bien sûr)
Je ne connais pas les contraintes de python, quelles sont les règles à respecter.
Qu'est ce qui est considéré comme une indentation ? une tabulation, une tab+1 espace, 2 tabs ? c'est la même chose ?
pour la fin de bloc, si j'ai fait une tab+1 espace en ouverture, 1 tab ferme le bloc ?
L’avantage de la compilation, c'est que ça ne s’exécute pas tant que la compilation a échoué. En python, la syntaxe du script est analysé avant déclenchement ? Je présume que oui.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
c'est la tuile pour python cette histoire si ca marche.
c'est le python tuile quoi
"Ritchie n’a pas de mots réservés, tout peut être redéfini."
Pour moi c'est une très mauvaise idée, chaque programmeur va prendre ses habitudes, et ça va compliquer
la lecture de codes écrits par d'autres
Moi je le vois plus comme un ensemble de surcouches [si le langage fonctionne"Ritchie n’a pas de mots réservés, tout peut être redéfini."
Pour moi c'est une très mauvaise idée, chaque programmeur va prendre ses habitudes, et ça va compliquer
la lecture de codes écrits par d'autres]: une surcouche C, une surcouche Java, , une surcouche Lisp, ...
D'autant plus que le langage adopte une syntaxe [sujet verbe COD-COI "je-ne-sais-pas-quoi"], donc une syntaxe caméléon... du moins sur le papier.
attention HS:
effectivement certains IDEs permettent de faire l'indentation pour les gens qui ne savent/veulent pas le faire. et le jour ou ces gens retrouvent avec un bête éditeur de texte (genre vi), ils font n'importe-quoi sous pretexte que l'éditeur n'a pas fait le boulot à leur place?
Python considère comme une indentation toute suite de caractères blancs en début de ligne: espaces, tabulations ou mix des deux (mais si on respecte les conventions, on évite les tabulations)
un bloc débuté par une indentation spécifique (disons 4 espaces, c'est la convention) contiendra toutes les instructions qui sont indentés de la même façon. une instruction sur 3 ou 5 espaces (ou avec une tabulation) mettra donc fin au bloc.
sinon, Python vérifie bien entendu la syntaxe au cours de la compilation en bytecode Python.
Mais pourquoi tout à coup on retrouverait juste avec vi ? Dans la vie courante, on a généralement l'occasion d'utiliser un IDE qui fait tout ça pour nous : indentation, formatage de code, détection d'erreurs, débuggeur, etc., etc.
Je sais qu'il y a des puristes qui considèrent qu'on doit tout savoir faire «à la main sous vi». Mais sérieusement, t'es développeur t'as envie de perdre ton temps avec un truc futile comme ça qu'un outil peut faire à ta place ? Tu n'as pas plutôt envie de te concentrer sur le fonctionnement de ce que tu codes ?
Je sais : un jour, on se retrouve à débugger le programme sur une machine de prod ou de test qui n'est pas notre machine de développement donc pas d'IDE, juste les outils fournis par le système (vi ou autre...). Mais bon là y'aura pas que l'indentation qui posera problème.
[EDIT] Après réflexion, j'irai plus loin : à partir du moment où la plupart des outils font ces trucs chiants à notre place, alors oui moi en tant qu'ingénieur je râle si on ne me fournit pas la technologie qui sait très bien le faire et qu'on me force à m'occuper de futilités techniques.
on peut se retrouver sous vi pour éditer du code qui tourne sur une cible embarquée par exemple.
alors effectivement on peut récupérer le fichier sur notre poste, l'éditer dans un bel IDE et le renvoyer sur la cible. si j'ai de grosse modification, c'est même probablement ce que je vais faire, mais pour des modifications mineures, ça me parait quand même plus simple d'éditer le fichier directement sur la cible.
le problème ici, vient du mot en gras. généralement, tout va pour le mieux dans le meilleur des monde. mais de temps en temps, on peut pas faire comme on préférais. et dans ces cas faut bien savoir faire du boulot pas trop dégueulasse...
je sais pas si je suis en train de passer pour un puriste qui considère qu'on doit tout savoir faire sous vi, mais ce n'est clairement pas le cas.
en général, je code sous Eclipse. quand j'utilise vi, c'est en général pour m'epargner des "soucis" pire que l'utilisation de vi.
sinon, sans parler de vi (parce que c'est un peu extrème) je bosse tous les jours avec des personnes qui codent sous Notepad++, et à ma connaissance, celui-ci n'est pas capable de te refaire une indentation complète. dans ce cas aussi c'est bien de savoir se passer de l'assitance.
tout à fait et c'est pas parce que l'indentation ne sera pas le seul problème que je ne dois pas savoir/vouloir m'en occuper. parce que à ce compte là, étant donné qu'on n'a rarement qu'un seul problème, on peut se servir de ce pretexte pour tout ignorer...
ça a l'air pas mal d'être ingérieur, on peut se permettre de râler pour tout et n'importe quoi
En fait on est presque d'accord.
Deux choses différentes : tu as raison sur le fait qu'on ne peut pas pragmatiquement ignorer ces choses parce que ça nous tombe dessus dans la vraie vie. Par contre ça me semble légitime de ne pas vouloir s'en occuper. Je veux dire, dans l'absolu, on s'en fout de ces broutilles.
C'est une façon de parler, je ne suis pas diplômé et je n'occupe plus la fonction. C'est pour mettre en valeur le fait que ce qui est intéressant, c'est de faire des choses «de plus haut niveau» que de gérer l'indentation et le formatage de code - et j'ai pas l'impression de demander grand chose là en fait =)ça a l'air pas mal d'être ingérieur, on peut se permettre de râler pour tout et n'importe quoi
Dans la vie professionnelle, on n'a pas toujours le temps ni les moyens de se former au dernier gadget sorti, la pertinence de l'outil doit être établie. Si le langage apporte des constructions nouvelles et réellement utiles (j'ai par exemple aimé les nouveautés de Python par rapport à Pascal), je ne conteste pas l'idée. Ce n'est pas tant le changement de syntaxe qui me dérange mais la création d'un outil qui sur le fond n'apportera pas grand chose. Ce qui me semble le cas pour Ritchie, la syntaxe est éloignée du langage qu'il est censé remplacer, cela aura sans doute du mal de convaincre les développeurs C.
Redéfinir des éléments syntaxiques : ne risque-t-on pas d'introduire des problème de compatibilité entre des sources d'origines différentes.
L'exemple de benchmark cité ne vaut absolument rien, juste des chiffres, il aurait fallu donner au moins les sources des programmes de tests. Un programme bien codé en Python peut donner de très bonnes performances bien qu'il soit interprété, Ritchie est compilé, la comparaison est donc baveuse.
Merci pour les feignasses mais le monde du développement, pourtant jeune par rapport à d'autres activités, est peuplé de langages qui n'ont pas eu une très longue carrière, les développeurs/entreprises qui ont investi dessus (cela prend du temps) peuvent se retrouver dans l'ennui. L'innovation est valable si pertinente.
Quand on travaille dans le développement, il n'y a pas que le langage de programmation, il y a aussi la connaissance de l'activité pour laquelle on travaille, cela prend aussi du temps. Les acquis permettent de travailler plus vite, tout simplement. Il faut comprendre outils au sens large (langage, IDE, bibliothèques et autres utilitaires). Tu tournes les arguments des autres d'une manière assez sournoise: penses-tu réellement que qu'en tant que développeur, on cherche à éviter de réfléchir, c'est une bien piètre opinion de notre métier.
un bel exercice intellectuel sans doute mais peut-être aussi une perte de temps.
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Panne de système et intervention en ligne de commande seulement, ça existe aussi. En outre, les serveurs ont assez souvent le minimum vital et donc pas d'outils de développement sophistiqués (hors activité sur ces machines)
tu as sans doute une conception de l'informatique assez idéale mais dans la pratique... Utiliser Vi n'empêche pas de se concentrer sur ce que l'on a à faire, affirmation gratuite.
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Oh mais j'ai déjà fait du debug sous vi, il y a longtemps. Aucun intérêt si ce n'est le destin qui le force (production...).
Vi est un éditeur bien plus que basique : tu peux très facilement faire indentation, formatage de code, détection d'erreurs, débuggeur, etc., etc. (oui oui débogueur pas à pas, lis ici si tu ne me crois pas)
C'est juste ceux qui n'ont pas envie de se donner les moyens (et je reste très poli mais j'ai du mal) qui sortent "autant utiliser un truc qui me fait tout". Parce que vim fait tout et bien plus encore.
Note que je travaille presque à temps plein sous PyCharm, mais qu'il faut savoir faire bien plus que << "vim" + "i" pour être en mode notepad >>...
Allez je te laisse sous Visual Studio .
Mais je réitère ma question : pourquoi je me «donnerai les moyens» (pour rester poli également) pour maîtriser un truc qui demande beaucoup d'efforts alors que pycharm par exemple est presque fourni clé en main ?
Moi j'ai besoin de bosser efficacement, pas de montrer qu'avec vi on peut tout faire et perdre mon temps dessus.
Conclusion : je ne veux rien paramétrer puisqu'on sait faire des outils qui gèrent tout. À la limite, des petits tunings pour la couleur et l'organisation de l'IDE. Par exemple je ne pense pas que je ferais du smalltalk s'il n'y avait pas les systèmes qui vont avec, parce que ça nécessiterai trop d'efforts et que je laisse ça aux passionnés (et ce n'est pas péjoratif). Même remarque pour vi.
Je comprend mieux et suis d'accord, le problème c'est l'apport et le problème que ça adresse et là c'est pas clair du tout.Dans la vie professionnelle, on n'a pas toujours le temps ni les moyens de se former au dernier gadget sorti, la pertinence de l'outil doit être établie. Si le langage apporte des constructions nouvelles et réellement utiles (j'ai par exemple aimé les nouveautés de Python par rapport à Pascal), je ne conteste pas l'idée. Ce n'est pas tant le changement de syntaxe qui me dérange mais la création d'un outil qui sur le fond n'apportera pas grand chose. Ce qui me semble le cas pour Ritchie, la syntaxe est éloignée du langage qu'il est censé remplacer, cela aura sans doute du mal de convaincre les développeurs C.
Pas s'il s'agit d'un DSL - si c'est pas un DSL ça n'a pas de sens - sinon ça s'adresse à un domaine spécifique et donc les utilisateurs finaux seront forcément beaucoup moins nombreux que ceux d'un langage généraliste. En conséquence ça n'a pas beaucoup d'impact et probablement que les différentes sources resteraient plus ou moins cloisonnées.Redéfinir des éléments syntaxiques : ne risque-t-on pas d'introduire des problème de compatibilité entre des sources d'origines différentes.
Le domaine métier n'est pas lié à la syntaxe du langage. Un nouveau langage comme celui là *pourrait* adresser un besoin particulier pour un domaine métier spécifique - ce qui reste à prouver ici. Donc ça se range dans la catégorie «outils». Se plaindre de la syntaxe (qui en plus est simple) pour justifier de se concentrer sur les langages «qu'on connait déjà», oui c'est de la fainéantise. Notre métier c'est bien de s'adapter et de savoir jongler intellectuellement entre beaucoup de choses...Quand on travaille dans le développement, il n'y a pas que le langage de programmation, il y a aussi la connaissance de l'activité pour laquelle on travaille, cela prend aussi du temps. Les acquis permettent de travailler plus vite, tout simplement. Il faut comprendre outils au sens large (langage, IDE, bibliothèques et autres utilitaires). Tu tournes les arguments des autres d'une manière assez sournoise: penses-tu réellement que qu'en tant que développeur, on cherche à éviter de réfléchir, c'est une bien piètre opinion de notre métier.
Je sais, je l'ai vécu et je tempère un peu lors de mes messages précécents. Je dis que c'est légitime de s'en plaindre.
Vi n'empêche pas de faire son boulot, évidemment que non. Par contre l'outillage de base est moins fourni et moins intuitif que d'autres IDE, par exemple on a cité pycharm plus haut. L'intérêt dans la pratique est d'avoir un truc qui marche tout seul qui permet de ne pas devoir systématiquement tenir compte de détails comme l'indentation - ou qui par exemple indique les erreurs d'indentation tout seul et visuellement avant d'avoir un plantage à l'exécution au sens large (compilation, interprétation...).
Entièrement d'accord, chaque langage a sa syntaxe propre, ses manières de gérer, etc...
Néanmoins, je maintiens que le fait de mettre les mots-clefs-qui-n'en-sont-pas-mais-qui-en-sont-quand-même après le test / la variable, je n'ai rencontré ça dans quasiment aucun langage -- seules quelques constructions de perl me font penser à ça (dans lesquelles on peut mettre le test après le code conditionnel, mais même dans ce cas, la lecture du test reste naturelle).
Alors certes, il existe certainement un ou plusieurs langages très peu connus dans lesquels on lit/dit/écrit "fait beau SI picnic ALORS", mais ce n'est pas l'ordre linguistique naturel (si des gens ici peuvent me confirmer que dans des langues non indo-européennes cette construction est respectée -- ou non -- j'en serai bien content).
L'ordre est une affaire de choix, tout dépend si tu veux mettre l'emphase sur la clause principale ou la condition.
Conditionnelle restreignant la clause principale :
- Accélère - sauf si le feu est orange.
- Stocke le résultat si c'est la première fois.
- On retourne le résultat s'il est différent de nul.
- Mieux vaut jouer la sécurité, du moins si l'on a des doutes.
Conditionnelle faisant partie du complément :
- J'ai parié qu'ils gagneraient s'il fait beau.
Répondre avec citation
Partager