Suis je fait pour la programmation

Bonjour tout le monde , je suis un zèbre mais je me pose cette question : j'adore l'informatique surtout la programmation malgré quelques problèmes de logique , je suis une formation par pole emploi qui a commencé la semaine dernière , le problème c'est qu'il nous fait un premier cours(cours à distance ) de php en démonstration sur de la programmation objet , du coup pas tout compris car j'ai besoin de manipulé pour comprendre , est ce normale ? Heureusement, les autres de la formations n'ont pas compris le cours .

malgré cela , ça me plait mais je doute de moi même ayant quelques problèmes de logique , j'ai déjà suivis des cours de programmation en lua pour programmer du jeux vidéo et j'ai adoré ! Tout ça pour dire que je me pose des questions si j'ai fais le bon choix , car quand je ne comprends pas je fuis le problème . J'ai du mal aussi à me concentrer .

C'est une logique à comprendre. Cela nécessite pas mal d'efforts personnels en dehors des cours...

Regarde là : https://openclassrooms.com/fr/courses/2818931-programmez-en-oriente-objet-avec-c/2818941-introduction-a-la-programmation-orientee-objet

Et là (plus orienté PHP) https://www.pierre-giraud.com/php-mysql-apprendre-coder-cours/introduction-programmation-orientee-objet/

Salut Antho (et bienvenue)

J'ai reçu plusieurs formations de programmeur, j'en ai donné aussi, sur de courtes périodes, à l'usage j'ai distingué trois profils :

- ceux qui percutent immédiatement, qui se passionnent et qui très vite n'écoutent plus que d'une oreille pour découvrir les possibilités par eux-mêmes ;
- ceux qui à un moment ou à un autre ont le déclic, d'un seul coup ils comprennent la logique interne de l'informatique et à partir de là tout se déroule et ils deviennent bons (mais ça peut prendre quelques mois);
- ceux qui ne percutent jamais, et dieu sait que pour certains, des amis, j'y ai mis du temps et du cœur mais ça fait pas partie de leur câblage interne, il y a un conflit de logique quelque part qui peut pas se résoudre.

Si tu appartiens à l'un des deux premiers groupes, aucun problème pour la prog, plus encore si tu as la passion.

Tu peux expliquer tes "problèmes de logique" ?

Pour moi si tu as déjà fait du scripting et que ça t'a passionné, que tu as compris ce que tu faisais et que le résultat final était au rendez-vous, c'est bon, t'es pas dans le troisième groupe

Sinon le test le plus simple, c'est l'inversement de variable :

Tu as deux variables, a et b, a contient la valeur 2, b contient la 5

Comment faire pour inverser les valeurs des deux variables en utilisant les fonctions courantes de la programmation.

Si tu y arrives tout seul, c'est gagné. Si l'explication* te paraît miraculeusement géniale et ouvre à ton esprit des myriades de possibilité, c'est gagné.

* solution:

Sinon de façon plus générale, effectivement j'ai croisé aussi les deux profils, les théoriciens qui construisent la structure logique dans leur tête, qui comprennent exactement ce que font les fonctions, à quoi correspondent physiquement dans la machine chaque appel logique qui est fait... Et les praticiens, ceux qui pratiquent le die and retry, qui compilent douze mille fois jusqu'à trouver le bon résultat, et qui ne savent pas exactement ce qu'il se passe dans la machine mais qui s'en foutent tant que le code est solide et que le résultat est exact.

Les deux approches se valent, perso j'adore apprendre théoriquement mais quand je code je fais beaucoup de die and retry, un peu un mélange des deux. Ne pas connaître parfaitement la théorie n'a plus autant d'importance que dans les années 80, où les ressources de la machine étaient plus que limitées et où il fallait optimiser chaque battement d'horloge, chaque accès mémoire et chaque stockage de variable. Aujourd'hui franchement, les ressources ne sont plus une limite, la théorie pure n'est plus un facteur absolument décisif.

Il n'y a pas plus logique qu'un ordinateur, ni plus binaire.
Si tu n'arrives pas à émuler cette logique dans ton esprit, ça va être très difficile pour toi de faire de la programmation.

Après, mettre les mains "dans le cambouis", c'est la seule bonne façon d'apprendre...

Ceux qui faisaient du pseudo-code au tableau en espérant que "quelqu'un" allait traduire et implémenter leur code, c'est fini..

Maintenant, il y a plein de code en open-source sur GitHub qui doivent te permettre de lire du code, et de te donner des idées.
Et c'est facile de s'installer PHP sur une distro Linux pour "jouer".

Ah, et pour permuter deux variables, on a pas besoin d'une variable intermédiaire.

A = 2;
B = 3;

A=A*B; // A= 2 x 3 = 6
B=A/B; // B = 6 / 3 = 2
A=A/B; // A = 6 / 2 = 3

C'est vrai

Il y a aussi la solution "école primaire"

A = A+B
B = A-B
A = A-B

Mais j'avais appris d'abord la première méthode et c'est cette "création ex-nihilo d'une variable pour te simplifier la vie" qui m'avait fasciné. Ça ouvre un tel champ de possibilités... Tu peux réfléchir en dehors de la boîte, ça devient même un objectif.

Bon, après à l'usage tu t'aperçois qu'en fait tu passes les trois quarts de ton temps à blinder le code, à traquer les bugs et à chercher comment faire fonctionner ton code dans 100% des scénarios possible, pas 90, pas 95, pas 99%. Mais quand même... Il y a une blague que j'utilisais en introduction de mes cours.

C'est un chirurgien, une prostituée, un architecte et un programmeur qui sont à table et qui discutent.

La prostituée parle, parle et annonce que tout le monde sait qu'elle fait le plus vieux métier du monde. Le chirurgien la reprend, c'est une femme et Dieu a créé la femme à partir d'une côte d'Adam, donc le plus vieux métier du monde c'est chirurgien. L'architecte intervient. Attendez... Au début était le chaos puis Dieu a organisé tout ça en sept jours seulement et il a bâti le monde à partir de rien, le plus vieux métier du monde c'est architecte.

Puis le programmeur se marre, tout le monde se tourne vers lui. " Et le chaos à votre avis, il venait d'où ? "

Le meilleur métier du monde et le plus vieux.

x = x XOR y
y = x XOR y
x = x XOR y

Voilà mon code :

A = 2
B = 5
NewA
NewB

NewA = B - A
NewA = NewA + A


NewB = B - A
NewB = B - NewB



Sinon pour des problèmes logique , je veux dire que j'ai la solution mais je n'arrive pas à la transposer ou parfois je vais trop loin dans mon developpement , je me complique la vie au lieu de faire du simple .

le XOR est le plus safe des 3 solutions proposées, les 2 autres solutions présentent un risque d'overflow et ne sont pas à recommander. D'un point de vue logique c'est parfaitement juste, d'un point de vue programmation, c'est donner de mauvaises habitudes.

Selon les langages il ya une fonction "swap".
Ce que je trouve dommage avec l'exemple (2,5) c'est qu'il est trop simple.
Essayer de permuter deux mots c'est également intéressant.

On devrait également se demander quel est l'algorithme le plus rapide.

Dans tout les cas ça va bouffer trois registres data dans le proc ...Enfin si j'ai bonne mémoire

Antho, ta solution fonctionne il manque juste la fin, A = newB et B = newA (du coup il valait mieux les appeler newA et newB que l'inverse, c'était plus logique)

Mais pour moi si tu arrives à trouver ça tout seul sans être guidé, ça veut dire que la logique est déjà là et tu ne devrais pas avoir de problème de compréhension majeur par la suite. En soi, à part le domaine très spécifique du BI (Business Intelligence) toute l'informatique utilise la même logique, si tu l'as de base, c'est OK.

Après, fuir les problèmes difficiles... Ca peut se contrebalancer par la passion, ca y'a que toi qui peut savoir. Si t'aimes bien, tu devrais quand même te motiver. Réussir à trouver la bonne façon pour contourner un problème difficile perso c'était un peu ma motivation, et ça fonctionnait, sinon j'ai aussi une forte tendance à laisser tomber.

Mais quoi qu'il en soit si tu veux te lancer dans une carrière professionnelle commençant par des études, ça reste assez probable que quelque soit la carrière à un moment ou à un autre tu te retrouves face à des défis et des difficultés. Alors autant en choisir une qui te plaît.

Pour la concentration idem... C'est très clair que programmer demande à se concentrer, un jour ou l'autre tu peux pas y échapper. Et idem, c'est là où le plaisir entre en jeu. Y'a que toi qui peut savoir, et faut pratiquer un peu pour voir.

Mais sinon, pour ta question initiale, avoir besoin de pratiquer pour comprendre c'est pas rédhibitoire en prog, c'est une façon de faire qui fonctionne — je laisse mes collègues reprendre ce point, si nécessaire.

@les autres : vous avez raison pour l'overflow, la vitesse et la mémoire... mea culpa autant apprendre tout de suite à faire les choses bien

---

Edit : l'overflow dans ce cas-là c'est dépasser la taille maximale que peut contenir une variable. Typiquement si ta variable peut contenir une valeur allant de 0 à 127, aucun soucis si A = 2 et B = 3.

Mais si A = 125 et B = 100... Quand tu fais A = A x B ou A = A + B, la nouvelle valeur de A va dépasser la taille maximale qu'elle a le droit d'avoir et ton programme va joliment planter. C'est ça la chasse au bug dont je parlais plus haut, couvrir 100% des scénarios. Ne jamais oublier que les valeurs de test ne sont qu'une valeur parmi d'autres... Et penser à tester toutes les configurations possibles, ou penser au moins aux deux limites extrêmes, haute et basse.

Oui j'avais pas mis à la fin car j'avais oublié , en faite j'ai juste peur de ne plus avoir de temps pour faire mon sport car j'en ai besoin dans ma journée . J'ai peur de devenir un stéréotype du geek .

ʦuke a écrit:
Edit : l'overflow dans ce cas-là c'est dépasser la taille maximale que peut contenir une variable. Typiquement si ta variable peut contenir une valeur allant de 0 à 127, aucun soucis si A = 2 et B = 3.

Mais si A = 125 et B = 100... Quand tu fais A = A x B ou A = A + B, la nouvelle valeur de A va dépasser la taille maximale qu'elle a le droit d'avoir et ton programme va joliment planter. C'est ça la chasse au bug dont je parlais plus haut, couvrir 100% des scénarios. Ne jamais oublier que les valeurs de test ne sont qu'une valeur parmi d'autres... Et penser à tester toutes les configurations possibles, ou penser au moins aux deux limites extrêmes, haute et basse.

C'est pas aussi simple que "ton programme va joliment planter". Tu ne peux pas prédire le résultat sans plus d'informations. Globalement, le swap a deux variable en utilisant l'addition a majoritairement des chances de fonctionner correctement (on va overflow dans un sens, puis de nouveau dans l'autre, le résultat sera juste malgré l'overflow). Le code ne sera pour autant pas portable. Sur certains compilos ou certains processeurs, le résultat sera différent, parce que le comportement en cas d'overflow ne sera pas le même.
Sur une multiplication c'est bien plus vicieux. Si tu overflow (avec un mode d'overflow standard qui consiste a jeter les bits "en trop"), ton résultat sera faux (soit très petit, soit négatif, selon ton type). Ca ne plantera qu'en fonction de ce que tu fais de tes variables.

Dans le concret c'est vraiment très important de connaitre les données que l'on doit manipuler, leurs types et leurs étendues.
Ca peut permettre des optimisations, parfois en pré-traitant les données, ou en les séparant vers différents algorithmes.

Nope, pour faire ça bien, et vite, on passe les pointeurs sur les variables.
Pas super intéressant avec des entiers, nettement plus avec les chaînes de caractères.

Code:

#include <stdio.h>

void swap(int *x,int *y)
   {
   int z;
    z   = *x;
   *x   = *y;
   *y   =  z;
   }

int main()
   {
   int num1,num2;

   printf("Entrer 1ère variable: ");
   scanf("%d",&num1);
   printf("Entrer 2ème variable: ");
   scanf("%d",&num2);

   printf("Avant Swap: %d  %d\n",num1,num2);

   swap(&num1,&num2);

   printf("Après Swap %d %d\n",num1,num2);

   return 0;
   }

Tu as raison 404 Je simplifie un peu trop... Ce type d'erreur "dans un programme complexe" peut finir par le faire planter, ou finir par donner des résultats faux sans plus d'indications que ça. Et ça peut aussi donner un résultat juste... Merci pour la rectification

antho a écrit:Oui j'avais pas mis à la fin car j'avais oublié , en faite j'ai juste peur de ne plus avoir de temps pour faire mon sport car j'en ai besoin dans ma journée . J'ai peur de devenir un stéréotype du geek .

Je suppose que tu dois être assez jeune, pour avoir peur de devenir un stéréotype. Je vais pas te faire le refrain habituel sur "deviens toi-même, ne t"inquiète pas du regard des autres", ça a beau être juste sur le principe c'est un peu trop convenu. Je vais juste préciser que le geek est devenu chic depuis pas mal de temps déjà, depuis que l'informatique domine l'économie en fait, et la pop culture avec. Et il est complètement possible d'être informaticien sans être un stéréotype, on est plus dans un film de Spielberg des années 80.

A mon avis, mais ça n'engage que moi, il vaut mieux avoir un emploi assez bien payé qui te passionne, avec un peu moins de sport, qu'être au chômage avec un corps de sportif. Ça vaut largement mieux. D'autant que tu peux finir par accomplir les deux, si tu as l'envie. Mais mine de rien, un bon emploi ça a son importance dans la vie.

Enfin... Juste un avis. Bonne chance pour la suite

Stegos : En mode Majax tu es excellent !
Pour manger :
Assiette pleine, estomac vide.
Je change les noms mais je ne déplace pas la nourriture.
Swap (assiette,estomac)
J'ai toujours faim !!

anthozebrato a écrit:Oui j'avais pas mis à la fin car j'avais oublié , en faite j'ai juste peur de ne plus avoir de temps pour faire mon sport car j'en ai besoin dans ma journée . J'ai peur de devenir un stéréotype du geek .

Super tu viens de formuler ton frein à main !!! Notons au passage comme L’esprit est fabuleux avec ses propres dérivations, sa capacité de contournement et d’évitement. En effet ce travail risque fort te prendre du temps. Mais ta formulation a aussi l’avantage d’énoncer la solution : le stéréotype. Tu n’es pas obligé de foncer corps et âme dans cette représentation. Tu ne vends pas ton âme au dieu Geek, qui se donne une séduction, avec ce renforcement positif du programmateur qu’il induit: Celui qui l’attèle à la tâche comme sisyphe avec son rocher. A toi de premièrement (attention je vais faire de la logique), d’inverser la valeur attribuée au métier de programmateur par ta propre valeur. De secondement mettre à la poubelle toutes ces représentations pour te façonner la tienne propre

petit drapeau

Stegos a écrit:
Ah, et pour permuter deux variables, on a pas besoin d'une variable intermédiaire.

A = 2;
B = 3;

A=A*B; // A= 2 x 3 = 6
B=A/B; // B = 6 / 3 = 2
A=A/B; // A = 6 / 2 = 3

Et sinon en python :

a, b = b, a  

Mais c'est de la triche, il y a de l'abstraction entre les deux (qui perso m'arrange bien, mon délire c'est d'éviter de produire des panzanis) 

D'ailleurs pour cette raison que je pense que le python est un bon langage pour une première approche, il amène une simplification. (ok ça permet pas de comprendre les choses en profondeur direct)
Mais cette simplification syntaxique et autres petits utilitaires (list comprehensions) permettent de se focaliser sur l'algorithmique et l'architecture (héritage, design pattern etc) qui sont je penses des concepts prioritaires.

Et par la suite descendre petit à petit pour affiner la compréhension des mécanismes sous-jacent. (Hors parcours universitaire bien sur)
Même si évidemment ça amène vite à des bêtises sous-optimales, mais peut-importe quand il s'agit de faire les premiers pas