Utilisez simplement Java
(teamten.com)- Mon langage préféré est Python. Malgré cela, j’utilise Java partout, même pour de simples scripts.
- Quelques expériences :
- Dans une entreprise basée sur Java, j’ai écrit des scénarios de test en JavaScript. Mais il était difficile de suivre les stack traces, et j’ai dû faire des efforts inutiles pour écrire du code de passerelle entre Java et JavaScript.
- Nous stockions les logs au format JSON, et un collègue a créé un programme appelé
logcatpour les manipuler. J’en étais satisfait, mais quand un programme similaire a ensuite été écrit en Java, il a montré plus de 10 fois les performances. - Grâce à la richesse de l’expérience et de la documentation autour de Java, Java était plus rapide que Python pour créer un service web. À strictement parler, c’est l’avantage d’utiliser un seul langage.
- Le débat le plus vif à propos de Java concerne sa verbosité. Mais ce n’est absolument pas un défaut. Regardez les deux codes ci-dessous.
// java
Map<String,User> userIdMap = new HashMap<String,User>();
// python
userIdMap = {}
- Mais en réalité, il est bien plus probable que le code Python soit écrit comme ceci. (Sinon, il sera vraiment difficile à maintenir.)
# Map from user ID to User object.
userIdMap = {}
- Autrement dit, utiliser un langage à typage dynamique revient à sacrifier la productivité à J+14 pour construire quelque chose de cool en 30 minutes.
- Stack Overflow a tenu 60,000,000 pages vues avec 5 serveurs en utilisant ASP.NET (en 2010).
- Prenons l’exemple des tests unitaires. Écrire et maintenir des tests unitaires prend du temps. En particulier, les cas d’exception qu’on peut simplement vérifier avec les types sont aussi difficiles à attraper avec les tests unitaires dans un langage à typage dynamique (ex. : un parseur).
- (Pour ajouter une des raisons pour lesquelles je n’utilise pas Python) une solution bricolée à la va-vite finit par grossir jusqu’à devenir un outil très important, mais comme on n’a pas le temps de la réécrire, on finit par souffrir à chaque utilisation à cause des performances et de la maintenance.
- Enfin, voici pourquoi je préfère Java aux autres langages à typage statique
- C/C++ est difficile à appliquer à mon travail
- C# manque de support cross-platform
- Scala est trop complexe
- D, Go et d’autres langages sont trop récents pour être introduits dans mon travail
- J’ai apporté cet article sur GeekNews pour plusieurs raisons :
- J’ai trouvé amusant de voir pour la première fois un article disant « J’aime vraiment Java ! » (en voyant seulement le titre, je pensais qu’il y aurait un retournement...)
- J’ai trouvé intéressant qu’il ait sa propre boîte à outils (faite en Java). Cela m’a fait penser à l’image d’un vieil homme sortant laborieusement des armes antiques de sa poche.
- Personnellement, j’aime beaucoup JavaScript et Python. Pourtant, à première vue, il semble que la tendance pour ces langages aussi soit d’« introduire le typage d’une manière ou d’une autre » (
typescriptpour JavaScript,typing/mypypour Python). En voyant cet article dans un tel contexte, je me suis demandé si le fait que j’utilise un langage à typage statique (sans imposer les types de manière stricte) ne relevait pas un peu de l’autosatisfaction.
- L’auteur a de l’expérience avec Java et Python, et a donc comparé directement ces deux langages, mais il ne me semble pas nécessaire de limiter la réflexion à cela. Dans une perspective plus large, que pensez-vous des langages à typage statique et à typage dynamique ?
PS. Évitons de rabaisser inutilement certains langages :D
58 commentaires
C'est peut-être une expérience très personnelle, mais je pense que le plus gros problème de Java, plus que le langage lui-même, c'est la JVM.
J'ai trop souvent constaté, sur plusieurs versions de la JVM, une mauvaise gestion de la mémoire.
Alors qu’on fasse aussi
pandasetnumpyen Java. Il ne faut pas garder près de soi ceux qui avancent ce genre d’arguments.On utilise Java pour les backends web, et Python pour l’IA. Si on veut vraiment parler performances, il faut utiliser Rust, non ? Ce n’est pas quelque chose que tout le monde sait déjà ? Mais comme la part de l’IA devrait augmenter à l’avenir, certains se disent peut-être que c’est le moment d’abandonner Java. En Corée, il y a souvent cet état d’esprit selon lequel il ne faut pas se laisser distancer, haha
Si l’IA devient très demandée et que les API REST classiques ou les simples tâches CRUD sont remplacées, au point qu’on ne construise plus ce genre de systèmes, alors on pourra peut-être abandonner Java.
Je pense aussi qu’on ne peut pas faire correspondre de façon univoque un langage et l’objectif d’un projet, parce qu’un projet n’est pas toujours constitué d’un seul langage. Il est courant, par exemple, d’avoir une interface de programmation en Python et d’utiliser du code natif pour les parties où les performances sont importantes. Cela dit, ce genre de composition de projet n’est sans doute pas très courant chez nous.
L’introduction est un peu décevante. Si vous nous aviez d’abord indiqué la date de rédaction du texte original, la moitié des personnes ici l’auraient sans doute comprise dans une certaine mesure...
Je m’en suis rendu compte aussi en voyant les commentaires des autres.
Mais j’ai supposé un peu vite que cela avait été écrit récemment, et je n’ai ressenti aucune étrangeté en lisant le contenu. Au moins pour moi, cela reste un texte convaincant.
Cela dit, je ferai un peu plus attention aux dates la prochaine fois lol
Le débat s’échauffe.
S’il y a des objections, merci de n’écrire que leur contenu.
Les commentaires qui ne respectaient pas les règles d’utilisation du site ont été supprimés.
Veuillez également noter que les comptes ayant répété des activités non conformes aux règles d’utilisation ont été bloqués.
Nous vous prions de maintenir un débat constructif.
Je fais davantage confiance à Google (V8) qu’à Oracle (JVM).
Quand j’ai découvert Java pour la première fois après avoir fait du Python, ça m’a vraiment paru très verbeux, mais quand je vois aujourd’hui tout le code nécessaire pour ajouter un typage complet en Python, je ne trouve plus ça si vrai que ça haha. Ce qui me déçoit davantage avec Java, c’est plutôt sa convention de nommage qui pousse à donner des noms de méthodes incroyablement longs.
1er juin 2014
Je préfère moi aussi les langages à typage statique.
Les langages à typage dynamique ont certes des côtés pratiques, mais il arrive souvent qu’ils deviennent plus difficiles à maintenir en environnement de production.
Et comme ces langages visent souvent, dans leur philosophie de conception, à permettre d’"écrire du code simplement", ils prennent en charge implicitement beaucoup de choses au niveau du langage ; de ce fait, il y a souvent moins de marge pour les optimiser.
Au final, entre la facilité d’implémentation et la marge d’optimisation, le mieux semble être de réfléchir en fonction de son environnement de développement et de choisir en conséquence.
Un article vieux de 10 ans, wow.
C’est vrai, haha
J’ai quitté Java, et ma vie est devenue plus paisible.
Il y a de bonnes raisons si Java continue de reculer dans le classement de popularité de l’enquête Stack Overflow.
En Corée, c’est surtout parce qu’on a imposé ce fichu framework gouvernemental basé sur Spring, donc c’est utile pour trouver un emploi, mais
dans le monde occidental, en dehors du legacy, choisir Java pour démarrer un nouveau projet semble presque avoir disparu.
C’est vrai qu’il y a des raisons à cela, mais j’ai l’impression que vous interprétez ces raisons différemment.
Le site TIOBE lui-même précise que le classement des langages doit être considéré uniquement comme une référence et qu’il n’est pas directement lié à la part de marché ou à la popularité.
La conclusion, c’est : Python est n°1 avec une part écrasante, mais existe-t-il vraiment des outils présents sur le marché ?
Les plus courants auxquels on est confronté sont C/C++, .NET, puis Java (Kotlin) et Swift.
Ce n’est pas parce qu’il y a beaucoup de questions et de recherches qu’un langage est forcément beaucoup utilisé.
Python est un langage que n’importe qui peut utiliser, même sans formation universitaire dans le domaine.
On ne peut pas nier sa popularité, mais sur le marché du développement, c’est une autre histoire.
Instagram utilise Python pour son backend.
La notion d’« outil disponible sur le marché » est un peu floue, mais... Django, FastAPI, PyTorch, NumPy, Pandas, etc., ce ne sont pas déjà des outils largement suffisants... ?
Je suis venu en m’attendant d’abord aux commentaires en voyant le titre, haha. Ces jours-ci, on a tendance à davantage compter sur les langages.
Si on se limite uniquement à la question du coût, Java finit par coûter cher dans le cloud à cause de son utilisation mémoire. Là où un programme écrit dans un langage statique a besoin de 100 ou 200 Mo de mémoire, il n’est pas rare qu’il lui faille 1 ou 2 Go en Java, et les threads légers sont souvent impossibles à utiliser à cause de problèmes de compatibilité avec les bibliothèques.
Java est aussi un langage statique, mais… les problèmes de mémoire relèvent du ramasse-miettes ou de la JVM, et le « programme en langage statique nécessitant 100 ou 200 Mo de mémoire » dont vous parlez correspondrait plutôt à des langages natifs comme le C ou le C++.
Désolé pour l’hallucination. TT Java est bien aussi un langage statique. En additionnant les différents coûts dans le cloud, il faut compter environ 30 000 wons par Go de mémoire, donc les services développés en Java finissent par engendrer des coûts très élevés.
S'il existe des exceptions, alors c'est un langage à typage dynamique. Par ailleurs, je suis d'accord avec l'argument selon lequel le système de types et l'utilisation de la mémoire sont deux sujets distincts.
Le sens de l’exception que vous mentionnez me paraît beaucoup trop large ; pourriez-vous l’expliquer un peu plus en détail ?
D’après la définition que je connais des langages à typage statique/dynamique, si le type d’une variable est déterminé à la compilation et qu’il faut le modifier explicitement pour le changer, alors c’est un langage à typage statique ; à l’inverse, dans un langage à typage dynamique, le type d’une variable peut être déterminé à l’exécution et peut aussi être modifié implicitement.
Lorsqu’on se retrouve dans une situation où l’on effectue un downcasting à l’exécution, Java doit vérifier les types au runtime. Pour cette raison, Java est à typage dynamique, et ce qui se produit alors, ce sont les exceptions.
Fondamentalement, si cet écart n’existait pas, il ne serait pas nécessaire d’appeler une exception une exception.
throwne serait alors qu’un sucre syntaxique pour un schéma consistant à stocker l’objet lancé dans une variable globale puis à faire ungoto.Comme vous l’avez dit, on appelle typage dynamique un langage qui effectue une vérification des types à l’exécution. Mais cela concerne toutes les valeurs manipulées dans le programme. Puisqu’il s’agit d’un article sur Java, si l’on prend Java comme exemple, le code Java est vérifié au moment de la compilation, mais cela implique aussi un point important : la valeur associée à cette variable doit correspondre au type de la variable.
Si le fait de vérifier les types à l’exécution suffit pour qu’un langage soit dynamiquement typé, alors le C aussi serait un langage dynamiquement typé ? Il me semble qu’il existe la notion de pointeur
void, mais quelle est exactement la différence entre les deux ?Quel compilateur C insère une vérification de type dans le code et déclenche une erreur explicite lorsque le type est incorrect ? S’il existe une telle implémentation, veuillez n’en citer qu’un seul exemple.
En C, il n’y a rien qui ressemble à une vérification de type dans ce processus. Lire des données en virgule flottante comme des entiers ne pose aucun problème, n’est-ce pas ? Ce n’est pas du typage dynamique, c’est juste dangereux.
Oui, si le C faisait sa vérification de type à l’exécution, ce serait un langage à typage dynamique.
Comme ce n’est pas le cas, c’est un langage à typage statique.
Un pointeur
voidest simplement un pointeur brut dont on ne peut pas connaître le type d’origine. On ne peut pas savoir quel type se trouve à l’adresse pointée par ce pointeur.Mon principe, c’est que le meilleur langage est celui qu’on maîtrise déjà.
Je suis d’accord. Il semble aussi qu’il ne soit pas facile de s’éloigner du langage utilisé par l’équipe ou l’organisation.
Parmi les différentes raisons pour lesquelles le contenu du travail ou les affectations se retrouvent cloisonnés, l’ajout d’un langage peut entraîner une surcharge de travail pour certaines personnes et empêcher l’avancement des tâches lors de changements d’effectif. Comme c’est aussi un facteur qui influe sur le recrutement, je pense qu’il faut être prudent dans le choix de la stack technique.
Cela dit, à l’inverse, s’obstiner à conserver un langage simplement parce qu’on y est habitué, alors que le vivier de recrutement est limité ou qu’un apprentissage supplémentaire est nécessaire après l’embauche, c’est aussi un problème.
Utilisez simplement Java
En quoi C# manque-t-il de capacités cross-platform ? De nos jours, la plupart des applications serveur .NET sont déployées sur des serveurs Linux.
Python n’est de toute façon pas comparable dès le départ et, par rapport à Kotlin et C#, il me semble bien plus verbeux et dépourvu de nombreuses fonctionnalités nécessaires.
Ah, c’est un article d’il y a 10 ans. La situation a beaucoup changé aujourd’hui.
Comme C# est aussi un langage qui utilise une machine virtuelle, la prise en charge cross-platform aurait dû arriver bien plus tôt, mais à ma connaissance elle n’est apparue que très récemment. C’est pourquoi je pense que, pendant un certain temps encore, l’idée qu’on s’en fera sera simplement qu’il peut tourner sur d’autres OS que Windows.
De plus, dans un environnement Linux orienté serveurs fonctionnant 365 jours par an, il est vrai qu’on hésite à adopter .NET, jugé moins éprouvé que d’autres langages dont la stabilité a été vérifiée depuis plus de dix ans sur ce type de système.
N’est-ce pas en ce sens qu’on dit que le cross-platform reste insuffisant ?
Mais au juste, selon quel critère considère-t-on que la stabilité est éprouvée ? Je ne comprends pas très bien si vous parlez simplement de la durée d’utilisation.
Comme c’est un article d’il y a 10 ans, il a été écrit ainsi peu de temps après les débuts de .NET Core.
Les applications .NET fonctionnent déjà de manière stable sous Linux et macOS.
Je cherchais par hasard s'il existait un langage avec une syntaxe concise à la Python mais avec du typage statique, et je suis tombé sur GDScript. Son gros défaut, c'est qu'il est très difficile à utiliser de façon générale.
Si vous en avez l'occasion, je vous recommande de faire un petit projet avec Godot pour goûter à GDScript.
J’ai découvert Kotlin et j’en ai développé une véritable aversion pour Java...
J’ai eu l’impression qu’en Java, chaque fois qu’on a besoin d’une fonctionnalité, il existe déjà une réponse éprouvée.
Utilisez simplement Kotlin.
Comme ça, j’ai moi aussi demandé par mail son avis sur Kotlin (en tant qu’utilisateur de Kotlin), mais il m’a répondu qu’il ne l’avait jamais utilisé, donc qu’il lui était difficile d’en parler d’expérience.
J’aime les langages à typage statique. Ils réduisent le besoin de réfléchir à certaines choses, ce qui me permet d’utiliser ce temps pour penser à autre chose.
Java occupe vraiment une place à part parmi les langages. La dernière fois que je l’ai utilisé au travail, c’était il y a une dizaine d’années, mais encore aujourd’hui, si je devais développer un programme pour un usage professionnel et non comme loisir, il ferait partie des langages que j’envisagerais en priorité.
Les principaux langages que j’utilise au travail sont actuellement Ada et le C, mais les outils que j’écris pour moi-même ou au sein de l’équipe sont surtout en PowerShell. Le problème, c’est qu’après un peu de temps à écrire, même juste cinq minutes, je me retrouve à me demander : « C’était quoi déjà le type de cette variable ? ». Du coup, ces temps-ci, je précise systématiquement les types. (En PowerShell, on peut indiquer le type à la définition d’une variable, ou l’omettre pour l’utiliser de façon dynamique.)
Je n’aime pas beaucoup le C non plus. Là où Ada aurait signalé des erreurs liées aux types à la compilation, le C ne les détecte absolument pas. Je me dis souvent que ce serait bien d’avoir un langage avec une syntaxe proche du C, mais avec le système de types d’Ada.
Je n’accroche ni à Javascript ni à Python. Perl ou les scripts shell… je préfère ne même pas y penser.
J’imagine que c’est inévitable à cause de la philosophie de base du langage C : « faites confiance au programmeur »...
Ah, et j’aime bien Java, mais je déteste Maven.
À la belle époque, on pouvait tout faire avec Ant !
C’est plutôt rassurant de voir que Java se modernise petit à petit, avec l’ajout des records et du pattern matching, et qu’il rattrape ainsi progressivement les langages plus récents.
Java a l’avantage d’avoir beaucoup de références, c’est bien, mais si ce n’est que pour ça, je me demande pourquoi ne pas choisir plutôt le C++.
J’aurais aimé qu’on parle un peu plus des avantages de Java.
J’utilisais simplement le C++ comme exemple, puisque c’est le langage que j’utilise principalement. Moi aussi, je pense que Java est un bon langage, mais ce que je voulais souligner, c’est que dans ce post initial, il manquait une explication sur les avantages de Java.
Si on écrit « J’adore Java », alors le sujet principal devrait être les points forts de Java, mais là, j’ai l’impression que l’essentiel porte sur la critique des autres langages.
Comme vous l’avez dit, je pense aussi que la JVM de Java est vraiment excellente.
Je suis tout à fait d’accord. La réserve disant qu’il ne fallait pas forcément limiter la discussion à Java allait dans ce sens. Mais il semble que cela n’ait pas vraiment été transmis...
Le fait que les points de comparaison soient Java et le C++ fait quand même pas mal chuter la crédibilité, lol.
Utilisez simplement Java.
Comme Java s’exécute sur la JVM, il est possible d’avoir la même configuration entre l’environnement local et celui des machines. Avec du C++, obtenir un environnement identique pour tous les développeurs et toutes les machines demandera beaucoup de temps. C’est aussi difficile à maintenir...
Il semble que l’auteur original utilise Java simplement parce que son travail se prête difficilement à l’usage de C++. S’il avait dû choisir entre Python et C++, il aurait sans doute choisi C++, non ?
corrigé : « Dernièrement, les raisons de ne pas choisir d'autres langages à typage statique » -> « Enfin, les raisons de préférer Java à d'autres langages à typage statique »
Le bois d’allumage prend bien feu… gros +1
Ce n’est pas l’incendie que je voulais snif
C'est... chaleureux...