[Nil]

[...] de toute façon, un programme, c'est 80% de réflexion et 20% d'écriture de code.

Tu oublie un point important : personne n'est parfait. Ce qui implique qu'il y a des bugs dans ton code (ou que le client veut ajouter quelque chose) et qu'une personne X va devoir modifier le code en question. Même si cette personne c'est toi, tu vas devoir relire ton code et comprendre ce qui se passe réellement avant d'oser modifier le code. Si la personne n'est pas toi, alors ça devient amusant parce qu'elle doit partir du début et chercher le problème, donc LIRE beaucoup de code.

Bref, "80% de réflexion et 20% d'écriture de code" c'est possible si le programme n'évolue pas et si tu code uniquement pour toi même, mais c'est rare. Il faut ajouter l'élément "lecture X%" qui prend une grande part aussi. Et c'est là que des langages plus lisibles gagnent des points parce que, finalement, on lis beaucoup de code dans une vie.

Et, honnêtement, même si l'écriture du code représentait juste 1% du temps de développement, j'aime quand même mieux un langage qui se lis bien

[Nalfein]

Ils ont tous des avantages et inconvénients en function de ce que l'on veut créer. Perso je développe pour une entreprise et on utilise PHP.

On vois tout de suite que t'est développeur PHP en tout cas  .

[Barti]

Moi je suis d'accord avec Nil, tu fais rarement un programme que tu vas jamais réutiliser, améliorer ou qui sera pas lu par quelqu'un d'autre, personnellement avant je codais comme un porc, maintenant c'est moins le cas et franchement y'avais un bête de truc que j'avais fait y'a longtemps quand j'ai voulu le relire pour l'améliorer je me suis dit que le réécrire serait plus facile tellement j'avais codé comme un porc, enfin après rien n'empêche d'écrire proprement en PHP (ou autre) et d'un autre côté comme un porc en Python (ou autre) et inversement...

[_o_]

Bref, "80% de réflexion et 20% d'écriture de code" c'est possible si le programme n'évolue pas et si tu code uniquement pour toi même, mais c'est rare. Il faut ajouter l'élément "lecture X%" qui prend une grande part aussi. Et c'est là que des langages plus lisibles gagnent des points parce que, finalement, on lis beaucoup de code dans une vie.

Je ne suis pas vraiment d'accord. La lisibilité et la maintenabilité du code dépendent pour une grosse partie de la conception de l'application, et du code produit. Le langage influe, mais dans une part négligeable du processus.

[Baelrog]

Développant intégralement en objet et sur un framework, j'insiste autant sur l'architecture de mes codes que leur optimisation en termes de temps d'exécution (je cherche pas à gagner 3ms mais rester dans des temps d'affichage convenable, de l'ordre de la seconde).
De plus, je respecte une autre règle importante, la portabilité des classes que je développe, il faut rester le plus générique possible. Rien de spécifique à une application à part quelques paramètres de config. Et quelques commentaires algorithmique au sein des process principaux n'est jamais de trop.

De cette façon, lors de mise à jour ou d'import de classes d'une autre appli, ca me prend rarement plus de 15-20minutes à installer. Presque du Plug & Play

Donc je maintiens, 80% de réflexion et 20% de code. Une appli bien conçu parle d'elle même.


@Nalfein: , en effet, je suis cramé Reflex linguistique, mais pour ma défense j'ajouterais que le "u" et le "o" ne sot pas loin l'un de l'autre !!

[Nil]

Donc je maintiens, 80% de réflexion et 20% de code. Une appli bien conçu parle d'elle même.

Tu ne semble pas avoir lu ce que j'ai écrit... Moi aussi je trouve assez facile de débugger/relire mon propre code. Même si une application est bien construite, elle a quand même été pensée par quelqu'un d'autre et cette personne ne pensait pas comme toi. Oui, tu vas être aidé par l'architecture (des noms utiles genre) et par les commentaires, mais qu'on le veuille ou non, du code ça se lis et ça prend du temps. SI le choix du langage peut aider à ce niveau, alors pourquoi pas?

@_o_ : Hummm, oui, tu as raison quand tu dis que la partie importante pour qu'un programme soit maintenable c'est avant tout son architecture.. Cela dit, même si ton modèle est awesome et que tu sais où trouver ce que tu cherche, tu vas arriver à une série de lignes de code. Rendu là, si tu as le choix entre le langage fictif BlubParadox (ultra expressif, requiert souvent la moitié de lignes que dans un autre langage X) et PHP, je ne vois pas pourquoi on devrait rester sur PHP... Uniquement parce que c'est ce qu'on a appris en premier? C'est une mentalité de religion ça ^^

[_o_]

Rendu là, si tu as le choix entre le langage fictif BlubParadox (ultra expressif, requiert souvent la moitié de lignes que dans un autre langage X) et PHP, je ne vois pas pourquoi on devrait rester sur PHP... Uniquement parce que c'est ce qu'on a appris en premier?

Je n'ai pas dit ça. Mais entre un langage que l'on maîtrise et un autre inconnu, il vaut mieux utiliser le langage que l'on maîtrise, pour ne parler que de la lisibilité. Donc dans le cas précis que tu cites, c'est peut-être PHP qui l'emportera. Note également que c'est de la théorie : dans une entreprise, il va falloir jouer avec les compétences internes, et si la majorité des devs ne sont compétents que sur BlubParadox, il faudra probablement oublier l'idée de PHP.

Ce que je veux dire dans tout ça, c'est qu'il est très réducteur de qualifier des langages de programmation sur leur type (procédural, objet, fonctionnel...), leur lisibilité (toute relative au regard des compétences du développeur qui lit le code), leur fonctionnalité (typage faible/fort, capacités objets, etc...). Une nouvelle fois, il faut trouver le compromis sur tous les aspects du projet (nombre de dev, compétences, archi techniques, exigences client, budget, planning...), et le choix du langage en fait partie.

[Baelrog]

Mais entre un langage que l'on maîtrise et un autre inconnu, il vaut mieux utiliser le langage que l'on maîtrise, pour ne parler que de la lisibilité.

En rentrant chez moi je repensais à ce post et c'est exactement ce que je me disais. Ce qui influe le plus sur la lisibilité d'un code est l'expertise que tu en as. Je dis un nom au pif, mais le Perl pourrait être beaucoup plus concis que PHP, il n'empêche que je ne connais pas ce langage et qu'au début je vais galéré un peu.

Après tu me diras, ya que les imbéciles qui n'évolue pas , mais comme le dis _o_, il faut faire avec certaines normes en entreprise, on ne peut pas laisser tout le monde faire sa tambouille dans son coin sinon ca devient ingérable. Mais grâce à ces normes, on part tous avec les même bases et l'utilisation d'un framework permet une cohérence architecturale et logique dans les applications, vu qu'elle sont imposées par le-dit framework.

[mathgl24]

Rendu là, si tu as le choix entre le langage fictif BlubParadox (ultra expressif, requiert souvent la moitié de lignes que dans un autre langage X) et PHP, je ne vois pas pourquoi on devrait rester sur PHP... Uniquement parce que c'est ce qu'on a appris en premier?

Je n'ai pas dit ça. Mais entre un langage que l'on maîtrise et un autre inconnu, il vaut mieux utiliser le langage que l'on maîtrise, pour ne parler que de la lisibilité. Donc dans le cas précis que tu cites, c'est peut-être PHP qui l'emportera. Note également que c'est de la théorie : dans une entreprise, il va falloir jouer avec les compétences internes, et si la majorité des devs ne sont compétents que sur BlubParadox, il faudra probablement oublier l'idée de PHP.

Ce que je veux dire dans tout ça, c'est qu'il est très réducteur de qualifier des langages de programmation sur leur type (procédural, objet, fonctionnel...), leur lisibilité (toute relative au regard des compétences du développeur qui lit le code), leur fonctionnalité (typage faible/fort, capacités objets, etc...). Une nouvelle fois, il faut trouver le compromis sur tous les aspects du projet (nombre de dev, compétences, archi techniques, exigences client, budget, planning...), et le choix du langage en fait partie.

Effectivement! J'ai eu à travailler dans une petite entreprise où eux, ils utilisaient PHP pour créer des modules Web que le client pouvait acheter par la suite. De plus, les noms de variable et de fonction doivent être nommés selon leurs règles. Bref, je n'aurais pas pu entrer là et dire que je ne programme qu'en python pour les avantages que Nil a nommés. De plus, si l'entreprise a tout codé en PHP, pensez seulement à tout le temps que ça prendrait pour tout réécrire le code en python... c'est inconcevable. Aussi, est-ce que les développeurs ont la compétence requise ? Si non, il faut les former et ça, ça c'est de l'investissement supplémentaire et ça demande beaucoup de temps.

Par expérience, juste le fait de migrer le code de PHP4 à PHP5 a demandé beaucoup de temps (les base de données MySQL vont de soi aussi). Donc, voilà pourquoi je suis d'accord avec les arguments de _o_.

[Nil]

C'est difficile de faire face à l'adversité!

Oké, je ne sais pas pourquoi c'est arrivé sur le sujet des entreprises (ma faute en fait), parce que ce n'est absolument pas mon intention de changer la façon de voir des entreprises. Ils ont décidé tout seul d'acheter Lotus Notes, d'utiliser uniquement les technologies Microsoft les plus chères (et Oracle pour payer un peu plus), d'acheter Webdev, de refuser d'utiliser de gestionnaire de sources, de rester sur la version 4 de PHP, etc. Bref, les compagnies décident tout seul de leur choix (et ce sont parfois de très mauvais choix, car c'est souvent des managers qui décident et ils savent pas grand chose, genre : "Hey, on va utiliser Waterfall parce que tout le monde en parle") et on ne peut rien y changer.

Ce que je *voulais* dire, c'est d'apprendre autres choses pour vous rendre service. Je n'ai pas appris Python pour me trouver une job (c'est rare des jobs en Python, croyez moi), je ne vais pas apprendre Go ou D pour me trouver une job, je vais le faire uniquement pour me rendre service. En quoi ça va me rendre service de "perdre" tout ce temps à apprendre? Eh bien, une fois que c'est appris, tu peux réaliser :
1) Est-ce "meilleur" que le langage que j'utilisais? Dans quel sens? Plus rapide, lisible, expressif, etc. Meilleure communauté? Divers outils de langage (support fonctionnel?, genre lambda, map, filter, reduce, support thread?, beaucoup de fonctions/classes offertes?, support mémoire transactionnelle?, support XYZ?) Si le nouveau langage à "uniquement" 1 avantage sur l'autre, c'est, selon moi, une bonne raison de l'apprendre davantage et d'oublier un peu l'autre. Même si on était rendu "expert", on va être encore plus "expert" dans l'autre! Hum, non, mauvaise phrase. En gros, c'est plus utile d'être expert dans un meilleur langage que d'être expert dans un "moins bon" langage.
2) Est-ce que ce langage sers pour un type d'application en particulier. Si on connait juste un type de langage, alors on prend assurément le mauvais outil pour certaines applications. Ben quoi, pas de bruteforce en JS, Python, PHP, Ruby svp
3) Même si on découvre qu'on haïs ce langage et qu'il est un peu moins bon que X, vous aurez quand même appris un nouveau paradigme et ça peut vous être utile dans X. C'est un peu comme de la culture ;des fois ça ne sert pas de façon apparente, mais ça vous rend mieux informé et ça peut vous servir dans certains cas. Par exemple, j'ai appris Scheme et j'haïs ce langage, mais ça m'a terriblement servie! Ça m'a fait évoluer en C++, Python, PHP, PowerShell et pas mal tous les langages qui ont une petite partie fonctionnelle.