Discussion :

[Invité]

si "ces nouveaux langages qui apparaissent et qui n'apportent qu'un sucre syntaxique et rien de fondamental" ne te suffit pas comme justification, je ne peux rien pour toi .

Désolé je n'appelle pas ça une justification mais une affirmation gratuite.

[Pyramidev]

Maintenant, le débat sur "langage typé" ou "non typé"... bof... je ne vois pas trop où est le problème du langage non typé... j'aime bien javascript pour faire ce pourquoi il a été conçu, il suffit d'apprendre ses spécificités (et ceci est vrai pour toutes les technos).

L'un des principaux avantages du typage statique est que c'est une sorte de documentation dont on sait qu'elle est à jour. Cela permet à un nouvel arrivant de comprendre plus facilement le code qui a été pondu par ses prédécesseurs. Qu'est-ce que cette fichue fonction prend en entrée et quelles opérations peut-on faire sur ce paramètre ? Avec le typage statique, on voit tout de suite le type et, avec un simple raccourcis clavier dans l'IDE, on peut sauter directement à la définition du type en question. Par contre, avec du code qui abuse du duck typing et qui n'ajoute pas non plus de contrôles de type au runtime, il faut chercher récursivement dans le code appelant. L'abus du duck typing est une manière parmi d'autres de concevoir des programmes qui sont de gros blobs que seul l'auteur comprend vite au lieu d'avoir un code bien découpé proprement en sous-parties qu'on peut analyser de manière relativement indépendante les unes des autres.

Même dans des environnements avec des langages dynamiquement typés, de plus en plus de développeurs finissent par comprendre que le typage statique peut être utilisé comme un atout pour la maintenabilité du code. C'est pour ça que le typage statique optionnel est apparu en Python et que le langage TypeScript est apparu pour ajouter du typage statique par dessus JavaScript.

comme si la valeur d'un programme se mesurait au nombre de lignes de code, moins il y en a, meilleur il est... alors que bien souvent, c'est le contraire

Cela me rappelle que tu étais dubitatif sur l'intérêt de la concision apportée par Lombok en Java. Je cite un de tes messages de février :

Personnellement, ça me prend 15 secondes pour faire générer les getter/setter, la méthode toString, le(s) constructeur(s), les méthodes hashCode/equals avec Eclipse alors je me demande : où est l'intérêt ?

Pour moi, si on peut générer tout ça avec des raccourcis dans Eclipse, c'est un signe qu'il s'agit de gros pâtés de textes qui ajoutent très peu d'informations, malgré la verbosité du code. Quand je lis du code, au lieu de faire défiler la barre verticale pour sauter la lecture du bruit, je préfère lire du code plus concis.

[sacdebille]

Il faut définir ce qu’est un développeur.
Car le programmation n’est pas la meme pour un core dev qui développe les bibliothèques qu’utilisent naivement les dev de SSII qui se prennent pour des demi-dieux. Et a mon sens, les core dev auraient sans doute un avis différents sur les langages les plus agréables.
Car régler les problème de memory leak ou d’optim sur les serveur d’appli c’est autre chose que de se poignarder le xxx avec des saucisses par ce que tel langage est moins verbeux que tel autre pour abonner un objet à un listener