Le topic de la programmation: Et envoyez des sioux!

[Kamasa]

Sinon, probable fin de partie pour Atlassian, en ce qui me concerne du moins.
https://www.atlassian.com/fr/migration/journey-to-cloud

Vers un avenir cloud, ensemble
SÉCURITÉ RENFORCÉE • FIABILITÉ ACCRUE • GESTION SIMPLIFIÉE • INNOVATION ACCÉLÉRÉE

Je vois pas pourquoi tu te plains de l'orientation qu'ils prennent

[ook4mi]

D'ailleurs je ne sais pas si vous lisez régulièrement la section hardware advanced, mais j'ai créé un nouveau topic là-bas pour des conseils de lecture :



Le fameux topic.

Je sais pas jusqu'à quel point tu veux descendre, cela me semble plus électronique que informatique non?

[Nilsou]

Vers un avenir cloud, ensemble
SÉCURITÉ RENFORCÉE • FIABILITÉ ACCRUE • GESTION SIMPLIFIÉE • INNOVATION ACCÉLÉRÉE

Je vois pas pourquoi tu te plains de l'orientation qu'ils prennent

C'est bien, à la fin il n'y aura plus que Gitlab, et le monde sera enfin en paix, en harmonie.

[vectra]

Toujours pas foutus de supporter le org-mode, tropisme windows un peu trop évident, gestion merdique des licences déjà acquises, SAV dans ton cul: je commence à avoir fait le tour de chez Atlassian.

[war-p]

C'est bien, à la fin il n'y aura plus que Gitlab, et le monde sera enfin en paix, en harmonie.

La CI de gitlab

[gros_bidule]

J'ai jamais vu de problème

Pareil

En fait pour Eclipse, j'ai l'impression que c'est comme pour n'importe quel gros outil. Il y a une phase d’apprentissage qui peut rebuter, surtout si tu as déjà tes habitudes sur un outil concurrent.
J'ai déjà vu des collègues pro-Eclipse, et purée, ils maîtrisent leur IDE tout comme il faut. Debug, couverture de code, git, etc... tout semble bien fonctionner bien chez eux, efficacité maximale. Ils ont peut être appris à contourner quelques bugs, mais c'est pareil sous n'importe quel IDE.

IJ a peut être plus la cote car il a une esthétique top-moumoute et c'est une boite qui promeut bcp ses outils
Mais je me rappelle mon premier essai d'IJ, vers 2012, et purée, c'était lent, lourd, moche, et j'étais complètement perdu. J'ai continué sur NetBeans (mais ça aurait pu être Eclipse) que je maîtrisais, et me suis mis pour de vrai à IJ plus tard, dans un nouveau taff où les collègues, tous pro-IJ, étaient là pour m'épauler et me donner plein de conseils sur comment utiliser IJ. C'est seulement après ça que j'en ai fait mon IDE principal. Sinon je serais peut être encore sous NetBeans, pestant contre cet IJ trop bizarre qui fait les mêmes choses mais pas de la même manière.

[Anonyme20240202]

La majorité des IDE se contentent d'utiliser un debugger existant, genre gdb, et font simplement de l'affichage.

Perso j'aime pas Eclipse simplement car rien n'est intuitif et la gestion des dépendances à base de click et de location absolue donne la gerbe. Y'a p'têt un moyen de faire ça proprement mais bon, jamais testé.

Je me souviens des cauchemar ou j'arrive et pull un projet eclipse tout ça pour voir que ça se réfère à des path de la machine du mec qui a push, et que pour se rendre compte de ça en premier lieu il faut click droit sur des dossiers (spéciaux de Ecplise! propre à l'IDE) pour voir des chemins, et y'a aucun document, non propriétaire, qui centralise le projet de manière self contained, mis à part ptet un vieux format propriétaire dégueulasse et illisible il me semble. 'Fin bref.

Même un projet tout nu avec simplement les sources et de quoi compiler (make, une commande gcc, ce que tu veux) me paraissait plus propre.

J'aime bien l'approche de CLion avec CMake (même si certes CMake a ses travers) et les outils standards.

C'est à dire que mon projet CLion, n'importe qui veut s'en servir, peu importe l'IDE, alors que loader un projet Eclipse sans Eclipse, putain quelle angoisse.

Comme d'habitude y'a sûrement moyen de faire ça bien, mais jusqu'à présent jamais vu ça pour Eclipse.

Et ouais c'est moche. Mais bon ça c'est autre chose. J'ai aussi pas mal de bug graphiques, et y'a pas moyen d'avoir plusieurs fenêtres (diviser son espace de travail) en même temps si mes souvenirs sont bons. Du coup si tu forward ça avec X11 c'est encore plus dégueulasse, bref.

Vraiment pas mon truc.

[Anonyme20240202]

Ah j'ai rien dit pour les plusieurs fenêtres, j'ai un vieux projet Eclipse qui traine et j'avais déjà fait ça. Je pensais p'tet à ces histoires de workspace

[Dross]

Ah ouais, VS Code, un bon outil… Finalement je ne m’étonne plus trop que tu apprécies Electron

Tu serai surpris, j'ai vu les plus bourru des barbus s'attendrir devant VS Code.

Et en effet, j'apprécie Electron, je sais faire du desktop natif mais pour certaines app c'est carrément plus adapté, pas d'un point de vu technique puriste, mais d'un point de vu "time to market" et effort nécessaire pour faire quelque-chose.

On peux bien faire les fines bouches et dire que c'est mieux de faire du Qt/WPF/etc, mais le truc c'est que pour faire une app moderne avec ça te prendra 4 fois plus de temps.

D'ailleurs depuis qu'on a Electron Linux deviens de plus en plus viable car les outils sortent en même temps sur toutes les plateformes.
Ça change du temps de Gimp et autre où il leur faut 4 ans pour rajouter un bouton.

[Tramb]

Yeah mais ont-ils le même écosystème ? Python n'est pas très rapide, mais ça suffit pour énormément de cas d'usage, et tu auras plein de libs pour faire ce que tu veux. Comme en Java et JS (liste absolument non exhaustive), qui ont aussi chacun un super écosystème. Du moins... il est connu par les masses.
Parfois aussi, le choix de la techno est fait parce que la team qui fera la maintenance ne sait faire que du Pyhon

Certes, certes, Shakira est plus populaire que Mahler :D

Plus sérieusement, on est d'accord, mais Python n'a vraiment que la popularité pour lui par rapport à d'autres langages, à mon sens.

[Mr Slurp]

Certes, certes, Shakira est plus populaire que Mahler :D

Plus sérieusement, on est d'accord, mais Python n'a vraiment que la popularité pour lui par rapport à d'autres langages, à mon sens.

Bah je dirai que python a pas la popularité pour faire des application UI, mais pour tout les outils de traitement de fichier en masse / automatisation, ou dans le domaine de la recherche en AI, il est franchement sur le devant de la scène. Suffit de voir à quel point les librairies de NN tel que TensorFlow mettent en avant le package python, au détriment du maintient d'un build C++ fonctionnel sur toutes les plateformes.

[Tramb]

On est d'accord, Python c'est fait pour remplacer bash, pas pour plus

Et oui, c'est le langage de glu le plus populaire, je dis pas le contraire.

[Helix]

En traitement du signal et d'images, il s'installe de plus en plus en remplacement de Matlab.

[rOut]

On est d'accord, Python c'est fait pour remplacer bash, pas pour plus

Et oui, c'est le langage de glu le plus populaire, je dis pas le contraire.

Pourtant c'est pas du tout adapté, pour lancer des processus et piper des trucs c'est juste l'enfer en quantité de code par rapport à ce que tu ferais avec bash. C'est surtout fait pour faire des petits scripts de traitement de données, pour remplacer awk ou sed quand ce que tu veux faire deviens légèrement plus compliqué.

[gros_bidule]

Je pense que c'est une affaire de goût. Je préfère passer sur du Python quand je vois que je n'arrive plus à relire un script bash.
Parce que bon, en bash on peut faire de sacrés trucs, mais quand tu pipes 4 ou 5 commandes un brin compliquées et qui t'obligent à relire le man (dont awk ou sed, comme tu l'as fait remarquer), pfiouuu, je préfère un script Python certes 3 fois plus gros, mais aussi 3 fois plus explicite.
Et ça passera sous Windowze.

Côté dev, on s'en sert aussi en réseau. En ce moment je bosse sur de la virtualisation de réseau (de gros FAI), via la plateforme ONAP. On a le choix entre Kotlin et Python, on a commencé en Kotlin mais on migre tout sur Python. Les perfs sont largement assez bonnes, et, étant pourtant un dev JVM à la base, j'avoue que passer sur Python s'avère être très sympa, tant pour le dev que pour l'ops. Je maudits quand même les pip install qui veulent parfois compiler des trucs (alors qu'en Java tu DL des jars, c'tout), mais aucune techno n'est parfaite ^^.
Ha, et on a des libs Python pour causer avec des matos réseau, mais bcp moins de libs JVM ^^. Ca a clairement joué.

[ducon]

pip ? À part dans la Quête du Graal, j’évite.

[gros_bidule]

Tu m'intrigues. Que fais-tu à la place ?
Nan, parce que s'il y a mieux, je regarde volontiers

[Nattefrost]

Ce n'est plus vrai pour pip, à part peut être dans les domaines proches de la data science (scipy & co) qui utilisent beaucoup de bindings C/C++/Fortran - domaine que je ne connais pas pour être franc.
J'ai pas eu à compiler quoi que ce soit en python depuis 2-3 ans et l'introduction du format wheel (.whl). Et mon boulot c'est en partie de maintenir à jour les libs python de la solution de ma boîte (gros projet django).

[Cwningen]

awk et sed, ce sont leur propres langages de scripts, c'est plus vraiment du bash. La force de bash c'est la facilité de manipuler des processus et des fichiers, mais le reste est horrible (d'où l'intérêt de souvent le mélanger avec d'autres langages de scripts comme awk ou sed, voire perl ou python). Si il y a des astuces pour manipuler aussi facilement les processus et leurs E/S en python, je veux bien un cours.

La meilleure alternative à pip, c'est le gestionnaire de paquet de ta distribution (je regarde toujours là en premier).

[ducon]

Tu m'intrigues. Que fais-tu à la place ?
Nan, parce que s'il y a mieux, je regarde volontiers

Je n’ai pas d’usage professionnel de Python, c’est juste pour moi. C’est pour ça que je me limite à installer les bibliothèques dont j’ai besoin via apt.

[Tramb]

pip ? À part dans la Quête du Graal, j’évite.

Meilleur ldvelh.

- - - Mise à jour - - -

awk et sed, ce sont leur propres langages de scripts, c'est plus vraiment du bash. La force de bash c'est la facilité de manipuler des processus et des fichiers, mais le reste est horrible (d'où l'intérêt de souvent le mélanger avec d'autres langages de scripts comme awk ou sed, voire perl ou python). Si il y a des astuces pour manipuler aussi facilement les processus et leurs E/S en python, je veux bien un cours.

La meilleure alternative à pip, c'est le gestionnaire de paquet de ta distribution (je regarde toujours là en premier).

Ouais quand je dis bash, c'est évidemment la fête à cut, sed, awk.

[jilbi]

Je me souviens des cauchemar ou j'arrive et pull un projet eclipse tout ça pour voir que ça se réfère à des path de la machine du mec qui a push, et que pour se rendre compte de ça en premier lieu il faut click droit sur des dossiers (spéciaux de Ecplise! propre à l'IDE) pour voir des chemins, et y'a aucun document, non propriétaire, qui centralise le projet de manière self contained, mis à part ptet un vieux format propriétaire dégueulasse et illisible il me semble. 'Fin bref..

T'es sûr que c'est pas le mec en question qui a push ses fichiers de config persos comme un porc ? J'ai bossé sur une version d'eclipse pendant 4 ans et les seules problémes de compilations que j'ai eu c'est justement quand les gens faisait de la merde avec le .gitignore et poussait les fichiers specifiques à l'ide.

Sinon l'histoire avec attlassian, c'est chaud,surtout qu'ils revoient les tarifs en fevrier. Aprés, je pense que les pme s'en foutent elles sont déjà en cloud, c'est le bon contexte pour forcer ça (je me souviens que notre sysadmin avait galéré pour nous ouvrir le gitlab en télétravail).

[Captain_Cowkill]

Salut les canards !

Je pose mon drapeau ici. En effet, suite à un gros questionnement professionnel j'ai décidé de me lancer dans la programmation. Je ne sais pas encore parfaitement dans quoi je veux me lancer mais depuis une semaine je fouine un peu partout pour apprendre les bases du C++ et je pense aussi jeter un œil côté Python. Le but sur le moyen/long terme est de me lancer dans une formation avec mon compte CPF et de me reconvertir totalement. Depuis que j'ai mis le nez dedans c'est devenu une étrange addiction.

Voilà, c'était une tranche de vie. Je vais jeter un l'œil à l'OP.

[Charmide]

La classe, on finira par les convertir tous

Tu serai surpris, j'ai vu les plus bourru des barbus s'attendrir devant VS Code.

Tout à fait, faut vraiment pas être à jour (ou pas vouloir l'être) pour déclarer péremptoirement que c'est de la merde. Je me rappelle avoir essayé Atom (même base electron) y'a quelques années alors que je jonglais entre vim et sublime, et effectivement c'était du caca (perf/réactivité, écosystème, j'en passe). VSC maintenant, t'as le droit de pas aimer, mais c'est plus la même. Un peu comme Microsoft qui n'est plus la boîte qu'elle était y'a 15 ans, mais y'a toujours beaaaaucoup d'inertie dans les têtes.

[deathdigger]

Salut les canards !

Je pose mon drapeau ici. En effet, suite à un gros questionnement professionnel j'ai décidé de me lancer dans la programmation. Je ne sais pas encore parfaitement dans quoi je veux me lancer mais depuis une semaine je fouine un peu partout pour apprendre les bases du C++ et je pense aussi jeter un œil côté Python. Le but sur le moyen/long terme est de me lancer dans une formation avec mon compte CPF et de me reconvertir totalement. Depuis que j'ai mis le nez dedans c'est devenu une étrange addiction.

Voilà, c'était une tranche de vie. Je vais jeter un l'œil à l'OP.

En première approche, je te déconseille quand même le C++. Java, C#, Python oui, C++, tu vas plus te dégouter qu'autre chose (et c'est pas là où t'auras le plus de taf).

[FB74]

Je suis de l'avis de Deathlamortquicreuse.

Java a au moins le mérite d'avoir certains automatismes (garbage collector) que le C++ n'aura pas.

Je ne fais pas (plus) de programmation, mais je pense qu'il vaut mieux passer par autre chose avant de tâter du C++ (que je n'ai jamais pratiqué d'ailleurs).

[Dross]

Académiquement j'ai commencé avec le C, puis le C++ et mon premier job a été avec C#. Je pense au contraire que c'est pas un mal de commencer avec des langages plus bas niveau pour bien comprendre certains concepts qui sont cachés après, et de passer ensuite à des langages modernes pour le coté productif (si adapté, bien entendu).

Je parle des bases en C et C++ hein, pas d'aller développer une application complète avec du UI, multi-threading et tout.

[Tramb]

Salut les canards !

Je pose mon drapeau ici. En effet, suite à un gros questionnement professionnel j'ai décidé de me lancer dans la programmation. Je ne sais pas encore parfaitement dans quoi je veux me lancer mais depuis une semaine je fouine un peu partout pour apprendre les bases du C++ et je pense aussi jeter un œil côté Python. Le but sur le moyen/long terme est de me lancer dans une formation avec mon compte CPF et de me reconvertir totalement. Depuis que j'ai mis le nez dedans c'est devenu une étrange addiction.

Voilà, c'était une tranche de vie. Je vais jeter un l'œil à l'OP.

Si tu veux partir sur des bases saines : https://htdp.org/
Après ça tu peux bouger sur Python sans souci. Et apprendre des trucs plus bas niveau.

Autre approche, plus bottom up, commencer par de l'assembleur et du C.
Les deux marchent

[deathdigger]

Académiquement j'ai commencé avec le C, puis le C++ et mon premier job a été avec C#. Je pense au contraire que c'est pas un mal de commencer avec des langages plus bas niveau pour bien comprendre certains concepts qui sont cachés après, et de passer ensuite à des langages modernes pour le coté productif (si adapté, bien entendu).

Je parle des bases en C et C++ hein, pas d'aller développer une application complète avec du UI, multi-threading et tout.

C'est vrai tant que t'es étudiant, et que donc t'as le temps d'étudier
Quand t'es en reconversion, il vaut mieux chercher un langage haut niveau (plus simple) et bankable (plus facile de trouver du boulot), quitte à se former après sur des concepts plus compliqués.

Personnellement, j'ai commencé avec du VB, avant de faire du PHP (spaghetti) puis du Java/.Net,etc
Je n'ai jamais étudié de langage bas niveau, mais je comprends les principes de pointeurs et autres vu que j'y suis confronté.

[FB74]

Académiquement j'ai commencé avec le C, puis le C++ et mon premier job a été avec C#. Je pense au contraire que c'est pas un mal de commencer avec des langages plus bas niveau pour bien comprendre certains concepts qui sont cachés après, et de passer ensuite à des langages modernes pour le coté productif (si adapté, bien entendu).

Je parle des bases en C et C++ hein, pas d'aller développer une application complète avec du UI, multi-threading et tout.

Je suis d'accord, mais je partage l'avis du creuseur de mort ( ).

Moi j'ai fait de l'info "à mon niveau" dans les années 80, j'avais même regardé un poil d'assembleur sur Amiga (et même du langage machine sur les calculettes HP48SX).
Donc même si je suis LOIN de connaitre tout, je pense avoir quelques bases dans le "comment ça fonctionne".

Et c'est vrai que lorsque tu fais une formation, on ne s'embarrasse pas de tout ça, on va directement au langage évolué (ce qui fait que les gens ne savent pas ce qui se passe derrière et ne comprennent pas le concept "d'optimisation"... ).

Mais pour du boulot avec une formation "courte", t'as pas le temps d'aller trop en détail, surtout avec plein de trucs "utiles" (= utilisés au boulot) à intégrer.