Quel est votre langage préféré en 2015?

Quelles technologies préconisez-vous pour 2015?

a marqué ce sujet comme résolu.

Pour Laravel, il y a passablement de changements en passant à la V5, mais surtout au niveau de l'organisation des dossiers/fichiers. Pour les nouvelles features, je ne les connais pas encore, je vous redirai quand j'aurai testé. Selon la majorité des développeurs l'utilisant, ces changements apportent réellement quelque chose, mais il faut que je m'y penche :)

Concernant le site de ma femme, au départ, c'était uniquement pour qu'elle puisse partager des liens vers des exercices externes (Wordchamp, tu nous manques…) ou des documents hébergés sur sa Dropbox. Ca c'était en 2010 ^^. Actuellement j'ai pas mal bossé dessus, et elle peut :

  • créer (et éditer) des exercices en WYSIWYG, merci TinyMCE (de type question-réponse, qcm, textes à trous). On arrive gentiment à un millier d'exercices pour le site, dans les branches Français, Allemand, Anglais (élèves de 12 à 15 ans).

  • lier des images à ces exercices, ou des fichiers audio/vidéo ou des liens youtubes, dailymotion etc… pour des compréhensions de textes, ou autre

  • gérer des groupes d'élèves (classes)

  • donner des devoirs à ces groupes (donner un exercice en devoir, avec pourcentage de juste requis, date limite pour le faire, etc…)

  • consulter les résultats des élèves, par groupe ou individuellement. J'ai fait une page où elle peut par exemple imprimer les résultat d'une période (définie par 2 dates), pour tel élève ou groupe, avec le détail des devoirs effectués ou non. La feuille est ensuite à faire signer aux parents (c'est la technique du bâton, mais ça marche plutôt bien). "Du xx.xx.2014, votre fille/fils a effectué x devoirs sur y donnés.". Au début de l'année scolaire, on distribue une fiche explicative pour les parents, pour la grande majorité, ils sont plutôt contents du système, qui permet un suivi.

  • j'avais imaginé également de passer l'ancienne BDD de la bibliothèque de l'établissement, qui a été conçue sous Filemaker, à une version liée au site (avec des QRCode derrière les bouqins, tout ça), mais l'idée n'a pas été acceptée par la direction (bizarrement, aucun soutien de ce côté-là pour le site).

Voilà pour les fonctionnalités jusque-là. J'aimerais bien avoir plus de temps pour bosser dessus, mais avec mon boulot et les enfants, je dégage pas beaucoup de temps libre :) (mais quelle heure est-il bon sang ???).

Le système est prévu pour pouvoir être ouvert à d'autres établissements scolaires, mais pour le moment, ce n'est pas d'actualité. Le site fonctionne bien, plusieurs profs et classes l'utilisent gratuitement (hébergé en mutu sur OVH, ça me coûte pas un bras non plus). Par contre, en début d'année scolaire, pour gérer les nouveaux élèves à entrer, et les questions que j'ai sur le site de la part d'élèves ou de profs, ça me prend pas mal de temps. J'ose pas trop imaginer si c'était ouvert déjà à deux établissements…

Je dois aussi dire que je ne suis pas fier de certaines portions de code, qui sont de mon niveau, c'est à dire très moyennes. Du coup, le site reste un peu fermé sur lui-même pour le moment :)

Pour la petite histoire, les premières versions étaient en PHP vanilla, que j'ai appris justement pour faire ce site. Ce n'était plus possible à maintenir, une catastrophe (c'était le foutoir absolu).

J'ai testé 2-3 framework ensuite, mais j'ai pas accroché. Puis j'ai essayé d'en créer un petit pour répondre à mes besoins, mais c'était trop limité et j'ai perdu pas mal de temps pour le faire. A la sortie de Laravel 4, j'ai testé, et j'ai adoré. La syntaxe était claire et… belle. L'ORM bien pensé, une structure MVC (si on le souhaite) que je comprenais bien, et aussi, une réelle simplicité d'apprentissage. Je pense que comme framework pour débuter, il est assez indiqué. Je dois bien avouer que la sortie du site Laracasts.com m'a bien aidé, la formation y est très didactique. Il y a aussi 2 blogs en français, ici et là qui m'ont bien aidé. A côté de ça, les ressources en anglais ne manquent pas actuellement.

Le site a été recodé avec, puis une deuxième fois de fond en comble, et actuellement je compte le passer sous Laravel 5, si j'arrive pour la reprise en septembre (ça va être chaud :)).

EDIT : Si quelqu'un veut un aperçu rapide de Laravel, cette petite vidéo présente quelques bases.

EDIT 2 : comme mentionné par @viki53 ci-dessous, je ne m'étendrai pas plus sur le site en question, c'est HS ici :)

+0 -0

Allez ça va me faire la fin de soirée (et ça va être court :-D) :

Quelle technologie/langage (et éventuellement Framework)? Python (Django).

Les plus/avantage moins/inconvénients? Trop peu expérimenté pour répondre.

Quel EDI utilisez-vous? Eclipse, Pycharm (payant mais je recommande pour tous ceux qui tâtent le Python).

Quel type de projet? Perso, Entrainement, Masochisme du cerveau.

Pensez-vous évoluer vers un(e) autre? Non. J'ai déjà du mal avec mes projets en cours.

+0 -0

@leir : C'est déjà un gros investissement pour un projet qui te coûte de l'argent mais ne t'en rapporte pas.

Pour le coup il te faudrait juste un système d'import d'utilisateur (via un fichier CSV par exemple) pour te faire gagner pas mal de temps à la rentrée et le tour serait joué ! Et ça te permettrait te t'ouvrir à d'autres établissements…

Dire que tu n'es pas fier de ton code est, comme on dit, une faute avouée donc à moitié pardonnée. ;) Quand on voit comment des systèmes vendus des milliers d'euros sont bancales et bricolés, dis-toi qu'avec un framework comme Laravel, tu as de grande chance d'avoir fait un truc assez propre. Après rien ne t'empêche d'envoyer le code à quelques personnes ou de le publier sur un repo git pour obtenir des retours et te permettre d'améliorer des points sensibles…

(Au passage, il vaut sans doute mieux continuer ça dans un topic à part, fin du HS, désolé les gens)

+2 -0

Natalya -> Tu n'utilises pas HAL ?

Tick

HAL ? Pour moi ça signifie Hardware Abstraction Layer, donc évidemment j'en utilise, chaque système un peu complexe a le sien.

Natalya

Je viens de me mettre depuis peu à l'embarqué (avec du ARM Cortex M4) et ce que j'avais compris c'était que le HAL était une sorte librairie par dessus CMSIS pour simplifier la programmation (en tout cas éviter de faire du bas niveau). Donc au final la partie CMSIS on l'a voit plus trop.

+0 -0

Personnellement, j'ai découvert Rust en fin d'année 2014 et je pense que la très grande majorité de mes projets personnels se feront dans ce langage. Il a plein de trucs pour lui et il est assez agréable à utiliser, même si certaines choses sont un peu énervantes et qu'il faut parfois s'arracher plusieurs fois ses cheveux pour réussir à compiler le bousin.

J'essaierai sans doute de faire un article pour la sortie de la v1.0 stable (parce que là, niveau stabilité… comment dire ? x)).

PS : Pour le boulôt, je ne code finalement pas des masses, mais les projets que je peux avoir sont surtout codés en C et/ou en Assembleur. Dans les deux cas (persos/boulots) j'utilise vim, parce que vim c'est bien :).

+0 -0

De ce que j'ai pu en voir/lire, Backbone est plus orienté interaction serveur et s'occupe moins du DOM. Ember et Backbone nécessitent jQuery, chose qu'Angular ne fait pas (<3).

Sinon, il y a un bon comparatif (en anglais) ici : https://www.airpair.com/js/javascript-framework-comparison (on se rend d'ailleurs compte qu'Angular est loin devant en terme d'utilisation)

viki53

J'ai aussi lu les différents comparatifs mais le deuxième ou premier lien google que j'ai eu avantageait ember lui donc… x)

Merci pour le retour. Je vais encore chercher pour être sûr de savoir quoi prendre mais apriori si je pars sur Angular, ça sera la V2.

+0 -0

Chacun sa préférence je suppose. Ou chacun son besoin, si on veut faire les choses bien (c'est bien beau d'avoir un outil qu'on aime, mais s'il est pas adapté c'est pas très utile)…

D'ailleurs avant d'utiliser un framework, une librairie ou tout autre outil, renseigne-toi bien sur son apport réel : ça reste des outils assez lourds aux performances pas toujours idéales (notamment sur les vieilles machines et les mobiles), il faut donc les utiliser avec précaution…

+0 -0

Salut,

  • Quelle technologie/langage (et éventuellement Framework)?

Nerothos

Le C.

  • Les plus/avantage moins/inconvénients ?

Nerothos

Pour les avantages, en plus de ceux cités précédemment par Natalya :

  • simplicité conceptuelle ;
  • contrôle élevé du déroulement du programme (comprendre : peu de choses cachées au programmeur) ;
  • langage de prédilection pour la programmation système, il permet de plonger dans le fonctionnement des OS (quand le code source est disponible, évidemment).

Inconvénients :

1
void
  • Quel EDI utilisez-vous ?

Nerothos

Un quoi ? :p

  • Quel type de projet ?

Nerothos

Je n'ai pas véritablement de projet, je suis simplement curieux et le C me permet d'assouvrir cette curiosité.

  • Pensez-vous évoluer vers un(e) autre ?

Nerothos

Si c'était le cas, ce ne serait pas une évolution. :-°
Plus sérieusement, non, aucun langage ne m'a autant satisfait pour l'instant.

+1 -0

À mon tour !

  • Quelle technologie/langage (et éventuellement Framework)?

Nerothos

Étant débutant et ayant un esprit papillon par nature, voici tout ce que j'ai regardé en 2014 (liste non-exhaustive et non chronologique) :

  • Swift
  • Objective-C
  • Python
  • HTML
  • CSS
  • PHP
  • Ruby
  • Javascript
  • Java
  • C++
  • Haskell
  • C

Actuellement, j'ai décidé de m'attarder sur le C, pour profiter du fait qu'il soit bas niveau afin de comprendre au maximum les mécanismes de fond qui régissent un système.

  • Les plus/avantage moins/inconvénients ?

Nerothos

Je n'en ai pas fait assez pour en parler, je fais donc confiance à Natalya, Taurre et les autres qui en ont parlé avant moi pour ça.

  • Quel EDI utilisez-vous ?

Nerothos

XCode, même si là aussi j'en ai testé pas mal.

  • Quel type de projet ?

Nerothos

Pour le moment rien de plus que les exos des cours, j'aimerais vraiment trouver un véritable objectif pour me motiver plus.

  • Pensez-vous évoluer vers un(e) autre ?

Nerothos

Après avoir regardé à droite à gauche pendant 6 mois, je vais me concentrer sur le C pour le moment, ce sera déjà une grande avancée ;) !

+0 -0
  • Quelle technologie/langage (et éventuellement Framework)?

Le langage OCaml, je commence vraiment à prendre plaisir à utiliser ce langage, moi qui au début ne comprenait jamais quand mettre des ;; et quand il ne fallait pas.

  • Les plus/avantage moins/inconvénients?

Le typage statique est un clair avantage. Le système de module force à compartimenter le code. Le système du type est en général très puissant, notamment la notion de type union. Pour les inconvénients, il y a les petits trucs chiant, du genre, les opérations arithmétiques pour les flottants sont différentes de celles pour les int, les int sont plus petit que la moyenne. Parfois la bibliothèque standard n'est pas non plus très fournie. Une autre chose est que je n'ai toujours pas trouvé une utilisation pratique du système d'objets.

  • Quel EDI utilisez-vous?

vim et la ligne de commandes, emacs de temps en temps.

  • Quel type de projet?

Principalement des projets universitaires et perso et des petits exos de programmation du genre projet euler.

  • Quel point de vue avez-vous? (utilisation/formation : projet perso, projet professionnel, autre)

Celui d'un étudiant.

  • Pensez-vous évoluer vers un(e) autre?

J'essaye de me mettre à lisp/scheme mais vu que en même temps je fait joujou avec haskell / scala, c'est difficile de se concentrer.

+0 -0

Lu'!

  • Quelle technologie/langage (et éventuellement Framework)?

Cette année, très probablement Why3, (peut-être) OCaml (même si ça me gonfle), C, C++.

  • Quel type de projet?

Why3 pour fabriquer une potentielle logique pour raisonner sur les programmes concurrents. Mais les vrais programmes concurrents : ceux qui font peur parce qu'on regarde ce que fait vraiment le processeur, et que ça fait pas du tout ce qu'on pensait ; ceux où on trouve que mince, les mutex et les sémaphores c'est pour les faibles, que nous on est des durs, des tatoués, et qu'on n'a pas besoin de ça.

D'ailleurs à ce propos :

Et les processeurs x86 sont vraiment mal foutus. J'ai commencé, cette année à m'intéresser à l'assembleur ARM, et dans l'ensemble, il est carrément mieux foutu […].

Dominus Carnufex

Définitivement, le modèle mémoire de ARM est le comble de l'horreur. Même pour les gens fous qui travaillent sur ce que j'ai dit juste avant c'est source de cauchemars, c'est des histoires qu'on se raconte au coin du feu pour effrayer les copains.

OCaml, ça me plaît moins, mais la plateforme pour laquelle je veux étendre Why3 est réalisée dans ce langage donc bon …

C parce que c'est le langage qu'analyse la plateforme en question. En ce qui me concerne je suis de plus en plus convaincu que C++ est plus adapté pour le concurrent. La présence d'objets soumis à un mécanisme de construction/destruction est un avantage indéniable pour garantir la localité d'invariants et pour raisonner de manière modulaire sur les programmes.

C++ parce que … c'est mon pote. Plus sérieusement, je trouve que C++ est l'avatar de la citation qui se trouve dans ma signature. Il offre la possibilité de choisir le niveau d'abstraction nécessaire, là où c'est nécessaire.

  • Les plus/avantage moins/inconvénients?
  • Why3, avantage : nombreux prouveurs automatiques compatibles, syntaxe légère ; inconvénient : ça reste un langage formel, et dans le formel il faut penser à tout (mais genre, à tout).
  • OCaml, ne se prononce pas.
  • C, avantage : simpliste ; inconvénient : simpliste.
  • C++, avantage : permet facilement l'approche "je fais un programme qui marche, je l'optimise". Une fois les bonnes pratiques acquises, on peut très vite faire une conception robuste qui tient la route et qui n'aura pas des performances minables. Une fois la conception validée, on peut facilement bencher et booster les morceaux trop lents sans rien péter (sauf si on n'a pas respecté l'ISP et le DIP bien entendu :lol: ). Inconvénients : ticket d'entrée élevé, enseignements pourris, le comité C qui lui lie les mains en terme d'héritage à conserver.
  • Commun avantage à C11 et C++11 : un modèle mémoire, qui marche … putain de bien quoi. (Même si les compilateurs le pètent bien entendu).
  • Quel EDI utilisez-vous?

Why3Ide, emacs.

  • Quel point de vue avez-vous? (utilisation/formation : projet perso, projet professionnel, autre)

Why3, Caml, C -> boulot

C++ -> perso

  • Pensez-vous évoluer vers un(e) autre?

Je réfléchis de plus en plus à commencer la création (en mode "expérimentation à l'arrache") d'un langage de programmation qui reposerait sur une sémantique formelle forte.

EDIT : en fait la fin aurait limite plus sa place dans un topic "le langage de mes rêves" … je le met en secret pour pas polluer.

Les constatations que j'ai envie de mettre à l'épreuve sont les suivantes :

  1. Un typage fort et compile-time permet d'avoir des programmes plus robustes dans un contexte avec une sémantique claire,
  2. Les niveaux de visibilité facilitent l'organisation et l'abstraction (donc la maintenance),
  3. Faire un truc qui tient formellement la route, c'est dur,
  4. Avoir un seul paradigme introduit des contraintes qui peuvent varier de l'acceptable au carrément galère,
  5. L'introduction d'un paradigme dans un langage qui ne le possède pas est bordéliquement complexe,
  6. Les exceptions facilitent l'organisation de la gestion des erreurs,
  7. Les exceptions rendent la gestion fine des ressources foutrement complexe (voir impossible) à grande échelle,
  8. Les GC sont vachement intelligents, ils sont capables de prouesses pour gérer les ressources,
  9. Certaines ressources sont très simple à gérer à la main quand on a un mécanisme comme le RAII
  10. Les GCs se traînent
  11. Un programme où l'on prend la peine de trouver qui est responsable de quoi est plus robustement conçu,
  12. Tout mutable, c'est compliqué,
  13. Tout non-mutable, c'est hyper chiant (et parfois ça se traîne),
  14. La concurrence, c'est hyper important.

Donc dans l'idée 1 et 2 nous disent qu'on doit pouvoir définir des types qui font avoir une importance cruciale dans la fiabilité de l'ensemble. 3. Nous dit que ça va quand même pas être facile.

4 et 5 nous disent que finalement avoir des paradigmes c'est limitant, plutôt que d'avoir des langages orientés trucs, il pourrait être marrant de voir comment faire un langage non-orienté. Cela implique que peu de constructions doivent faire parti du langage en build-in mais qu'on doit donner énormément de liberté au programmeur pour créer ses propres constructions (boucles for (qui peuvent être à la C, façon iterator, etc.), pattern-matching, …). On peut alors intégré le paradigme dont on a besoin mais c'est hors du langage, c'est des bibliothèque de paradigme.

De cet ensemble, on se dit que le méta-programming devra tenir sévèrement la route si on ne veut pas voir l'exécutable mourir au lancement. Et si on veut faciliter ça pour le développeur, l'inférence de type devra être du tonnerre.

6 et 7 nous disent que malgré tout, avoir la possibilité d'utiliser des exceptions, c'est nécessaire si on veut pouvoir jouer à tous les niveaux. Mais ça implique d'avoir une politique de gestion des ressources qui tient la route.

8 à 11 nous dit que les GC c'est cool mais que finalement les doser ce serait pas mal. Je m'explique, dans une très vaste majorité des cas, nous ressources, on sait où elles sont : il y a machin là-bas qui a sa liste de truc et puis chouette dans le coin là qui a son tableau de bidule. Savoir qui possède quoi, ça fait parti d'une bonne conception. De la même manière pour une vaste majorité des objets locaux, leur libération est plus qu'évidente : quand j'arrive à la fin de mon bloc, j'en veux plus. Cependant 14., et en concurrence ben des fois, on s'aperçoit que le GC il serait bien plus balaise que nous pour gérer ce type particulier de ressource qui tue mes performances et mon empreinte mémoire. En plus si pas mal de GC se traînent, c'est pas simplement parce qu'on leur file une trop grande quantité de bazar à gérer ? A mon avis, si on donnait au GC juste les trucs qui sont vraiment excessivement complexes, ils feraient bien mieux leur boulot.

Donc dans l'idée : du RAII et objets managés (dit comme ça, ça ressemble à C++/CLI).

12 et 13, je pense que pour maintenir des performances honnêtes, autoriser les modifications in-place est indispensable. Et ça ne signifie pas abandonner toute stabilité. "Well specified programs don't go wrong", si on offre la possibilité de spécifier précisément les propriétés de nos programmes (et pourquoi pas de balancer ça dans des prouveurs tiens !), il n'y a pas de raison que ça se passe plus mal.

14, Il nous faut un modèle mémoire badass.

Voilà, voilà.

+1 -0
  • Quelle technologie/langage (et éventuellement Framework)?

En ce moment y'a pas mal de Javascript avec NodeJS en back-end et AngularJS en front-end. De plus en plus de Java aussi pour les nouveautés qu'on ne fera pas en Node. Et remplacer le "vieux" code à long terme.

Dès que ça passe sur du mini code indépendant et / ou du perso : python (parfois du shell bash).

  • Les plus/avantage moins/inconvénients?

Les directives Angular c'est bon, mangez-en, pour le reste je suis pas très à l'aise niveau front-end, mais avec ce framework ça va on s'y retrouve bien. J'étais bien plus perdu avec Durandal.

NodeJS c'est pas mal aussi, léger, rapide, souple ; mais bon sang les concepts d'asynchrone du JS … c'est pas mon truc, ou alors je suis toujours trop fatigué quand je suis dessus.

  • Quel EDI utilisez-vous?

IntelliJ, ça dépote ! J'avais testé aussi la version community de pycharm après coup pour chez moi c'est bien aussi. Par contre leur gestion de git … pouah ! Les termes ne sont pas les bons et ça masque pas mal d'opérations à mon sens. La ligne de commande c'est la vie.

Et sinon vim très très souvent.

  • Quel type de projet?

Y'a du web pour le boulot, du bricolage maison ou des exercices pour le fun sinon.

  • Quel point de vue avez-vous? (utilisation/formation : projet perso, projet professionnel, autre)

Pro et perso.

  • Pensez-vous évoluer vers un(e) autre?

Faudra que je tente un langage fonctionnel un de ces jours.

  • Autres

J'avais bien aimé passer 6 mois à faire du C#.

+0 -0

Inconvénients : ticket d'entrée élevé, enseignements pourris, le comité C qui lui lie les mains en terme d'héritage à conserver.

Juste pour dire : il me semble que c'est au comité de normalisation du langage C++ qu'il revient de décidé s'il se base ou non sur la norme C et quelle partie de celle-ci il souhaite voire respecter. Le comité de normalisation du C n'a rien à voir là-dedans.

+0 -0

@Taurre : pour être plus exact, des voix commencent sérieusement à pousser pour que C++ arrête de supporter C. Mais sans aller jusqu'à l'arrêt complet du support, ne pas prendre les nouvelles features serait déjà un bon point (tout le monde que ce soit du côté de C ou de C++ est d'accord pour dire que ces langages ne sont plus les mêmes et n'évoluent plus du tout dans le même sens). Typiquement lors de la normalisation de C++11, après que les travaux sur la concurrence aient été terminés (ou presque), le comité C est arrivé avec C11, avec aussi pleins de trucs pour la concurrence (mais pas du tout pareil, évidemment) et en disant "vous avez dit que pour cette norme vous respectez la norme C, faut intégrer ça", ça a été mal pris par mal de monde …

Mais bon, tout ça c'est de la politique.

+0 -0
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