Nouveau projet, quel language choisir ?

Oui, énième sujet de la sorte du web mais je n'ai pas trouvé satisfaction

a marqué ce sujet comme résolu.

Bonjour à tous, je me lance dans un nouveau projet personnel (à but potentiellement commercial) et je suis face au choix du langage. J’en est déjà pas mal discuté avec un ami qui connait beaucoup de langages et qui a fait beaucoup de projets différents mais essentiellement web. Et j’aime pas le web. Du coup une petite présentation rapide du projet mais surtout des contraintes pour le choix du langages s’impose.

Le but du projet est de donner une interface qui permette la rédaction d’histoires (roman, héroïc fantasy…) bien plus simple et intuitive. On oublie Word et on passe sur un véritable outil (Scrivener en vidéo).

Les contraintes : + Interface puissante. Je veux pouvoir faire une interface qui soit aussi souple que celles qu’on trouve dans le web (avec le puissant mélange HTML/CSS/JS). La partie interface est évidemment clé puisque le but est commercial et adressé à des gens pas forcément sensible à l’informatique (sans faire de préjugé). De plus j’aimerais qu’il soit possible d’avoir des interfaces qui se construisent automatiquement (à partir d’un fichier de config par exemple, un peu comme en HTML)

  • Structuration du code facile. Là c’est clairement pour moi, je suis assez organisé mais je n’ai jamais mené des projets de grandes taille. Ce critère me fait immédiatement penser à Java. Le gros avantage de Java (ou équivalent) c’est son système objet qui oblige à avoir une structure du programme correcte. Outre le fait que j’apprécie de langage, j’ai peur de me sentir très contraints à cause du fort typage (je code en python depuis 2 ans maintenant). Mais bon c’est un détail

  • Machine Learning. Particularité du logiciel, j’aimerais intégré du machine learning dans mon logiciel. Je ne développe pas trop puisqu’il s’agit de la vraie valeur ajouté mais il s’agit essentiellement d’analyse de texte (en même temps ce serait un peu bête de faire de l’analyse vidéo non ?). Du coup je pense à Python que je connais en plus assez bien.

Voilà mes 3 gros critères. J’aimerais un langage qui me permette une interface aussi flexible que du web, avec un paradigme objet fort et la possibilité de faire du calcul scientifique. A cela on peut ajouter les contraintes assez classiques multiplateforme, avec un bon support et surtout un langage haut niveau ; je veux pas m’embêter avec du C. La dernière contrainte étant que je puisse commercialiser le logiciel sans avoir à payer une licence développeur, ou alors vraiment pas cher.

Puisque j’y ai réfléchi, voici une liste des solutions trouvées et des avantages / inconvénients :

  • Java 100% : L’objet et le fort typage va permettre d’avoir un logiciel assez maintenable (bien sûr ça dépend de moi), les interfaces devrait être assez bonnes. Par contre j’ai peur qu’on ne puisse pas être aussi flexible qu’en web et surtout que le Machine Learning soit particulièrement difficile et lourd.

  • Python 100% : La partie interface et machine learning ne sont clairement pas un problème. Par contre le système objet en Python n’est pas fait pour être utilisé comme en Java et j’ai encore beaucoup de mal à m’y faire. Je risque de faire des bêtise et de développer un logiciel moins maintenable et évolutif qu’en Java, ce qui est très très gênant

  • Java 50% Python 50% : J’utiliserais Java pour l’interface et les fonctionnalités et Python pour le Machine Learning. Le problème avec cette solution c’est que j’ai peur de sacrément complexifier la chose et de devoir gérer les entités des deux côtés et c’est assez catastrophique pour la maintenance.

J’ai aussi pensé à du C# mais le fait que le logiciel doit être multiplateforme me paraît trop contraignant, mais peut être que je me trompe.

Merci d’avance de votre aide, n’hésitez pas à poser vos questions et me dire si je fais fausse route.

La bise

J’ai aussi pensé à du C# mais le fait que le logiciel doit être multiplateforme me paraît trop contraignant, mais peut être que je me trompe.

boarf avec .NET Core et ASP.NEt en libre, tu peux te lancer, au pire, docker quoi.

Sinon si tu aimes l’organisation, go peut être sympa, mais là c’est pas d’objet du tout.

Enfin, en python tu peux vraiment aller loin surtout si tu joues avec les packages (regarde le code de zds, ou bien le billet "note sur les packages en python".

Après j’aime pas java mais j’avoue que pour avoir travaillé avec l’injection de dépendance et l’IOC grâce à hk2, je comprends ton choix.

Pourquoi pas un front en HTML/js et un back en python sous forme d api ? Ça peut être completement cross plateforme (logiciel/web/mobile) selon le framework js choisi et tu gardes python en back pour le ML.

Pour l organisation tu peux ainsi séparer le back du front clairement et tous les framework js proposent une organisation du code et des projets scalable et en générale bien pensée.

+1 -0

Salut,
Je propose mon dada, C++/Qt :D
L’interface qml te permet la souplesse et la simplicité que tu peux trouver dans le web, avec une combinaison de langage descritif (qml) et de langage de scripting (javascript)
Qt est multiplateforme, tu pourra compiler ton projet pour toute les cibles
Le calcul est effectué en C++, profitant de la performance du langage compilé, de la programmation à bas niveau (avec une syntaxe relativement haut niveau, grâce au C++ moderne et au framework Qt), de la structuration de la POO, et de l’ensemble des bibliothèques disponibles en C++ (il doit surement y avoir des choses pour le machine learning).

Cependant je propose ça comme option supplémentaire, je ne sais pas si c’est la plus adapté, mais elle répond aux critères. J’ai peur que le qml soit un peu overkill pour une interface de traitement de texte, et que le machine learning soit trop compliqué en C++ (j’ai l’impression que les bibliothèques sont plus matures en python).
Tu pourrais aussi embarqué un interpreteur Python :p

PS : J’aime pas java non plus, j’ai vraiment l’impression que c’est un langage qui fait un peu de tout mais qui n’est au final adapté à rien. Les seuls cas qui me ferait l’utiliser c’est un développement spécifique pour Android car il s’agit du langage natif, et le développement d’application SmartCard car c’est un cas un peu particulier, et dans les deux cas j’y irais un peu à reculons.
Mais tout ça c’est un autre débat.

+1 -0

@Artagis : Il va falloir que je regardes plus en détail l’organisation en Python, je connais le système de module et de package mais il faut une meilleure rigueur qu’en Java ^^. J’ai regardé un peu Go sinon, j’avoue ne pas être très fan de manière très externe. Et j’ai peur de e pas retrouver toute les libs dont j’ai besoin pour le ML (j’ai pas cherché j’avoue)

@Demandred : Ca fait partie des idées que j’ai eu que je n’ai pas précisé. J’avoue être une bille sur tout ce qui touche au web, faut-il nécessairement lancer un serveur ? Si oui je n’aime pas du tout cette option. Pour l’interface en Python je sais que je pourrais faire ce que je veux et qu’au pire PyQt permet d’interpréter du web dans une fenêtre. Pour la séparation back/front, je compte de toute façon utiliser une architecture en MVC. Quand je parle de problème d’organisation c’est plutôt en référence aux Design Patterns par exemple.

@Leroivi : Je ne connais pas assez C++ donc j’ai peur de faire des conneries étant très habitué aux garbages collector. Mais effectivement ça fait partie des possibilités. Mais pour tout t’avouer, je ne vois pas l’intérêt supplémentaire de C++ par rapport à Python ^^

En tout cas merci de vos premières réponses. Je ne l’ai peut être pas précisé mais le logiciel a pour but d’être utilisé sur Bureau. Je ne pense pas le porter en Application, ou alors que certaines parties assez spécifiques et dans ce cas je ferais un développement à part. J’aimerais surtout faire un logiciel stand alone donc pas de serveur etc.

Je dirais surtout que ça dépend du langage avec le quel tu es le plus à l’aise.

Pour ma part ça serait le Java. Et pour le typage fort, je ne pense pas que ce soit le plus grand problème, ça te permet même d’éviter des erreurs étant donné que tu verras tout de suite si tu attribues un type que tu souhaites. Et si vraiment, tu as toujours la possibilité de surcharger les méthodes ou de passer par des interfaces.

@WinXaito : Prendre le langage avec lequel je suis le plus à l’aise n’assure pas de prendre un langage adapté au projet :). Je souhaite faire un projet conséquent et pourquoi pas le commercialiser. Commencer le projet "par préférence" n’est pas une bonne idée. Et je suis prêt à mettre le temps pour apprendre autre chose

@Cithoran : En fait si je veux pas du C++ c’est justement à cause des construction et destruction, c’est tellement galère ^^. Mais bon, encore une fois je vois pas la grosse plus-value par rapport à python

Mmmh, j’ai l’impression que tu te trompes un peu de cible parfois.

Déjà, changer de langage parce que tu as peur de comment ton code va être organisé et/ou difficile à maintenir ça me semble curieux.

Je pense qu’il existe des logiciels largement plus gros que celui que tu vas produire, et qui sont écrits en Python, en Go, en Haskell, etc.

Pour moi, la première solution serait de te documenter sur ce qui rend un gros projet facile à maintenir en Python, comment on implémente certains design patterns sans pour autant en foutre partout.

Ensuite, deuxième truc louche : Java pas adapté au machine learning. Y’a pas mal de libs qui existent et je serais vraiment très très surpris que tu sois limité par le langage et/ou le manque de bibliothèque en Java (reconnaissons-lui au moins cette qualité).

Pour paramétrer l’interface en XML, moui, pourquoi pas, en JavaFX y’a fxml. Pour moi ça fait partie des trucs qui pourraient rendre ton application difficile à maintenir. Je suis d’accord pour séparer la logique de présentation de tes écrans de la logique "métier" de l’application. Mais tant qu’à faire, y’a sûrement, dans plein de langages, des DSL (donc comme c’est du code, c’est plus facilement "vérifiable") qui permettent de créer la logique de présentation. Après tout, l’XML c’est presque une DSL, mais verbeuse, sans typage, etc. A mon avis, y’a mieux.

Je reviens sur les trucs louches : le fait de prôner la facilité de maintenance et ne pas désirer de système de typage "fort" (le typage de Java n’est pas ce que je qualifierai de "fort", j’aurais dit "mou" moi : il existe, il checke des trucs, mais il est pas spécialement pratique). Moi je dirais si tu veux un truc facile à maintenir, choisis un typage fort, au sens "costaud" du terme. Bref, un système où :

  • le compilateur est assez malin pour détecter la plupart des bêtises
  • tu peux t’appuyer sur le système de types pour faciliter le refactoring
  • tu peux carrément t’appuyer sur le système de types (en partie) pour modéliser ton problème

C’est un point de vue qui se discute, mais ça mérite d’être cité.

Quatrième point, la portabilité en Java, c’est avant tout l’affaire de la JVM, pas de Java. Et du coup, y’a ptet’ des pistes à fouiller de ce côté là. On a quelques officionados de Kotlin sur le site, qui a au moins l’avantage d’être moins cérémonieux que Java, mais y’a plein d’autres pistes

Enfin, la piste client-serveur, bah je plussoie un peu.

D’abord, est-ce-que tu es certain que tes utilisateurs voudront installer un logiciel sur leur machine ? Est-ce-que tu penses que ça peut représenter un frein ? Si oui… Aïe.

Ensuite, quid du mobile ? J’imagine que pour écrire du texte c’est pas la piste privilégiée mais pour le consulter ?

Enfin, la collaboration. J’ai peur que tu aies besoin, au final d’un serveur sur lequel stocker des utilisateurs, des groupes de travail etc.

+2 -0

Le reste du sujet me passionne peu mais juste :

mais si on gère de bout en bout leur création/destruction ça va

Cithoran

Cela va tellement bien qu’en moins de 45 secondes passées sur ton code, j’ai trouvé ça :

1
2
3
4
5
6
7
for (int i=0; i < this->root[map_name].size(); ++i){
   Block* block = new Block (
     this->root[map_name][i]["id"].asInt(),
     this->root[map_name][i]["colliding"].asBool()
   );
   temp.push_back(block);
}

Si push_back échoue, une exception sera levée, la mémoire allouée par ton new est perdue. Bref, non, ton code n’est pas correct (et avec le "level.clear()" plus haut dans ce même code, qui ne fait aucune libération avant de réduire le vecteur, il y a même plus besoin d’exception, on produit explicitement une fuite de mémoire).

Pitié, si vous faites du C++, utilisez les outils qui sont à votre disposition pour ne pas vous occuper de la mémoire. Dans le code précédent, le coût induit par l’usage de unique_ptr à la place du pointeur nu c’est :

  • 0 sur la lisibilité,
  • 0 sur les performances.

Par contre, ça évite d’écrire des deletes à tord et à travers.

Franchement, ce que ça m’inspire c’est que tu t’inquiètes sur le moins important.

Ton frontend, puisque c’est du web, sera indubitablement en html/js. Maintenant quel langage pour ton backend ?

Instinctivement j’aurais envie de te répondre Python ou Go, mais en réalité, on s’en fout !

Ce qui importe vraiment, c’est le design et l’architecture de l’API que ton backend va exposer au frontend. C’est ce qui conditionnera le plus la réussite de ton projet, et ce que tu pourras le moins faire bouger une fois sortie ta première release.

Derrière cette API, qu’elle soit implémentée en Java, en Python, en Go, en C# ou que sais-je, ce n’est pas un choix figé dans le marbre. Tu dois te donner le droit à l’erreur, le droit de te faire plaisir, le droit de tester des trucs, d’en refaire d’autres, et le seul point fixe de ton appli c’est que quelque soit le langage dans lequel tu développes ton backend, celui-ci respecte le contrat de ton API.

Pour ce qui est des questions de POO, de typage ou que sais-je, tu trouveras toujours des gens pour se contredire les uns les autres (c’est notoirement connu que j’aime qu’un typage ne vienne pas me chier dans les bottes, du moment que 70 % de l’effort d’écriture de tests passe dans les tests unitaires…). C’est pas ça qui pourra faire échouer ton projet. Par contre si tu foires ton API et que tu ne la conçois pas correctement, là la dette coûte très cher dès le début et peut plomber le projet entier.

+7 -0

Merci pour vos retours !

J’avoue être assez novice dans ce genre de problématiques (même si je code depuis quelques années, c’est essentiellement pour les cours). La manière dont j’en parle ici fait peut être pensé que je me concentre beaucoup sur cette décision mais pas du tout, je sais bien (et j’en ai l’expérience) qu’on peut tout faire avec tout. Cependant je préfèrerais partir sur de bonnes bases et étant un peu perdu j’ai souhaité demander votre avis (qui ma foi est particulièrement riche). Mais c’est une question qui sera résolu dans quelques semaines seulement, travaillant d’abord sur le cahier des charges puis la conception.

@Javier : Merci pour cette réponse très complète et intéressante. Je vais te répondre dans le désordre :

Pour paramétrer l’interface en XML, moui, pourquoi pas, en JavaFX y’a fxml. Pour moi ça fait partie des trucs qui pourraient rendre ton application difficile à maintenir. Je suis d’accord pour séparer la logique de présentation de tes écrans de la logique "métier" de l’application. Mais tant qu’à faire, y’a sûrement, dans plein de langages, des DSL (donc comme c’est du code, c’est plus facilement "vérifiable") qui permettent de créer la logique de présentation. Après tout, l’XML c’est presque une DSL, mais verbeuse, sans typage, etc. A mon avis, y’a mieux.

J’ai cité le XML parce que tout le monde connait, mais c’est tellement lourd que je ne ferais pas comme ça. L’idée étant de permettre l’utilisateur de créer ses interfaces simplement sans code (ou alors de la description) je ne veux pas le perdre. Je pensais plutôt partir sur quelque chose avec une syntaxe plus simple type YAML, mais pour le coup c’est vraiment un détail.

Ensuite, deuxième truc louche : Java pas adapté au machine learning. Y’a pas mal de libs qui existent et je serais vraiment très très surpris que tu sois limité par le langage et/ou le manque de bibliothèque en Java (reconnaissons-lui au moins cette qualité).

Quand je dis que Java n’est pas adapté au ML ce n’est pas à cause des libs mais de Java lui même. Je me suis habitué à la simplicité du code Python et à NumPy, en Java la syntaxe pour le calcul est très verbeuse. Mais oui je trouverais forcément de bonnes libs maintenues en Java.

Je reviens sur les trucs louches[…]. C’est un point de vue qui se discute, mais ça mérite d’être cité.

Je ne connais peut être pas assez bien les typages "costauds" alors puisque j’ai fait essentiellement du Java et du Python. Ca semble être une bonne fausse idée de ma part finalement. Dans ta description, tu penses à quoi comme langage ? Du C++ par exemple ?

Enfin, la piste client-serveur, bah je plussoie un peu.

Moi c’est la dernière idée que je prendrais xD. C’est peut être mon côté anti-web bête qui ressort. Je ne suis pas un fan du cloud et du tout en ligne, du coup j’ai du mal à en voir les avantages par rapport à un logiciel. De plus, le fait de s’adresser à des écrivains incite à faire réflechir à la confidentialité. J’ai peur que ceux-ci est moins confiance dans quelque chose "en-ligne", mais je me trompes peut-être, à moi de faire une étude suffisamment bonne pour en savoir plus. Et pour la partie collaboration de laquelle tu parles, c’est celle qui m’incite à faire quelque chose "en-ligne". J’ai cependant peut être une autre idée puisque je souhaiterais utiliser du Git pour les textes écrits, du coup s’il ne s’agit que de partage de texte cela posera moins de problèmes.

Ensuite, quid du mobile ? J’imagine que pour écrire du texte c’est pas la piste privilégiée mais pour le consulter ?

Je pense faire un développement séparé pour le mobile. Je me trompe peut être mais j’ai l’impression que c’est vraiment un petit nombre qui serait intéressé. Mais encore une fois, discuter avec des écrivains serait mieux.

Merci et désolé de cette réponse très longue.

@Nohar : Merci aussi pour ta réponse à laquelle je répond en partie dans le début de mon message :)

Ton frontend, puisque c’est du web, sera indubitablement en html/js. Maintenant quel langage pour ton backend ?

Mon front-end n’est pas forcément du web, ce que je veux dire c’est que j’aimerais avoir quelque chose qui soit aussi puissant. Il me semble qu’avec Qt on peut faire tout aussi bien et c’est plus ce genre de chose qui m’intéresse.

[…] du moment que 70 % de l’effort d’écriture de tests passe dans les tests unitaires

Là je vais devoir apprendre beaucoup puisqu’on nous apprend très peu à en faire à l’école. Mais vu que j’ai de bonnes pratiques à côté ça ne devrait pas être trop dur à apprendre.

Encore merci pour vos réponses

Bonjour Ricocotam,

Si tu aimes tant le langage Python et que tu souhaites utiliser YAML plutôt que XML.

Dans ce cas peut-être Ruby est un meilleur choix ?

Enfin qu’importe le langage que tu vas utiliser en toute franchise les gens ils ne s’intéressent pas aux langages utilisés sous le capot, c’est ce qu’ils voient avec leurs yeux qui est important.

Sinon pour les mobiles, il faudra retrousser tes manches, car mobile veux dire chacun son langage !

Sur Iphone tu dois utiliser Swift Sur Android c’est Java et sur Windows Phone C#.

+0 -0

@Ricocotam

Ce que j’aurais fait, c’est une API, ainsi qu’un front-end connecté à cette API.

Avantages?

Le frontend peux être un JavaFX, un Javascript, du .NET ou autre, on s’en fou. Du coup lorsque tu vas avoir fini une version Web/Desktop, rien ne t’empêche de facilement refaire une version mobile.

Désaventage?

Du coup l’application doit constament (ou presque) être connecté à internet. Mais il y a des stratégies avec du cache local et autre.

Quels langages j’aurais utilisé?

Kotlin pour le desktop, avec TornadoFx. Ruby ou Crystal pour l’API Vue.js pour le front web Kotlin pour le mobile Android Swift pour le mobile iOS

Ce n’est qu’une solution parmis tant d’autre, et présentent tous les qualitées que tu recherche (tout comme Python ou autre)

La vrais question, est: Comment veux-tu architecturer ton projet?

Je ne sais pas trop ce que cache dans architecture donc je vais essayer de répondre comme je peux. Sinon pour le reste de ta réponse, globalement la solution client serveur (donc API, je suis pas fou) est une bonne solution. C’est clairement la solution technique devenue classique. Cependant je n’aime pas personnellement cette façon de faire. Autre chose, que j’ai déjà évoqué vaguement, je m’adresse à des écrivains, qui cré donc un travail artistique et essaie (généralement) de le vendre. J’ai peur que beaucoup soit rebuté face à un logiciel nécessitant une connexion internet (parce qu’en plus ça empêche d’écrire partout). C’est comme si on t’obligeait à utiliser Audacity en étant connecté à internet quand tu compose une musique (je sais qu’on utilise pas Audacity mais c’est un exemple). Donc au delà de mes avis, je pense que ça pourrait être un frein à la vente.

Sinon, pour l’architecture. Je pense livrer un logiciel comme un Word est livré. Donc c’est un executable et derrière avec du code structurer en MVC (tout de même). Dans un premier temps, pas besoin d’internet, par la suite peut-être selon les fonctionnalités mais c’est très ciblé. Je sais pas trop quoi ajouté d’autres ^^

@Ricocotam

Petite précision:

Mais il y a des stratégies avec du cache local et autre.

Tu peux donc très bien créer l’application avec la possibilité de ne pas être sur internet.

La connexion permettrais par exemple de push les modifications faites en local sur le serveur :)

(ex: Git, qui s’utilise en ligne et hors ligne)

Après je peux comprendre que tu n’aime pas une architecture Client/Serveur ;)

Je pense livrer un logiciel comme un Word est livré

Skype est par exemple livré de la même manière (et nécessite internet pour utilisation), donc cela ne répond pas à la problématique. :)

JE suis surpris que personne n’ait encore cité NW.jS ou Elektron. Ca pourrait être une alternative intéressante à considérer.

Bon, c’est du JavaScript, donc sur la question du typage fort et du langage solide sans surprise, on a l’antithèse ultime.

Mais l’avantage c’est que tu fais une interface en HTML/CSS avec tout ce qu’il y a de bien dans le développement web, tout en restant totalement hors ligne si tu veux. En très gros raccourci, tu distribues une copie de chromium avec ton code HTML et JS…

Un certain nombre de gros logiciels s’en servent, visual studio code par exemple; donc il y a moyen d’aller très loin. ET pour le ML, avec toute la flopée de choses qu’on trouve sur npm je ne me fais pas trop de souci, ton bonheur doit sûrement s’y trouver.

Pour en revenir à Java, c’est mon premier langage de choix, mais je vais quand même être un peu méchant pour une fois. Pour faire du back-end web, c’est un peu compliqué à mettre en place au début mais solide et éprouvé. Par contre pour les applications de bureau, j’ai l’impression que Java est plus ou moins has been: Swing c’est obsolète; SWT a l’air de n’être que moyennement maintenu; si on veut faire du QT je ne vois pas trop l’intérêt de le faire en Java plutôt qu’en C++; et JavaFX je n’ai pas l’impression qu’il a convaincu tant que ça.

Dans tous les cas, Java sur le bureau c’est lourd à installer et pas forcément si simple qu’il n’y paraît pour l’utilisateur lambda. Donc non, pour faire une application de bureau, je n’ai pas envie de te conseiller Java.

+0 -0

Bon, c’est du JavaScript, donc sur la question du typage fort et du langage solide sans surprise, on a l’antithèse ultime.

Si je ne dis pas de bêtises, le JS actuel est quand même assez solide et performant, pour peu qu’on utilise les bons outils. Je pense qu’il faut choisir un langage adapté à son projet, selon les contraintes techniques et pas selon les goûts pour telle ou telle approche de la programmation. Et aussi faire avec ce qu’on maitrise comme techno.

ET pour le ML, avec toute la flopée de choses qu’on trouve sur npm je ne me fais pas trop de souci, ton bonheur doit sûrement s’y trouver.

Je ne pense pas que JS soit adapté du tout pour faire des calculs et donc du ML du fait de sa représentation des nombres en flottant. Et rien n’empêche d’avoir deux serveurs : l’un "classique" en js (ou autre chose) et un autre dédié au ML qui communique avec le front et l’autre serveur via une API.

je m’adresse à des écrivains, qui cré donc un travail artistique et essaie (généralement) de le vendre. J’ai peur que beaucoup soit rebuté face à un logiciel nécessitant une connexion internet (parce qu’en plus ça empêche d’écrire partout).

Tu as essayé de demander a des écrivains leurs besoins et leur avis sur le sujet ?

+1 -1
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte