totof2000 a écrit 9656 commentaires

Je ne suis pas contre les sujets HS, tant qu'ils sont bien signalés HS avec éventuellement le thème (ici j'aurais bien vu [HS] : Géopolitique).

Ce qui est un problème c'est de ne pas penser le développement comme une activité comme une autre ou le programmeur doit utiliser les outils adaptés pour être efficace.

Et si un type bien outillé avec un IDE puissant est plus efficace qu'un type mal outillé qui refuse d'utiliser l'outil adapté, le second a un problème, même si il rejette la faute sur le langage.

Attaque à peine dissimulé : personnellement je ne refuse pas d'utiliser un IDE : cependant il y a parfois des cas ou l'utilisation de l'IDE est impossible : typiquement, maintenir des scripts d'admin sur un environnement de prod, avec un vi "historique" (même pas vim) (ou notepad pour des machines Windows), sans possibilité de développer/tester sur un env de préprod ou de dev. Dans la vraie vie ça arrive (c'est ma vie en ce moment et ça ne doit pas être aussi rare que ça).

Franchement indenter des blocs c'est pas une fonctionnalité avancée pour un éditeur de code, c'est un truc basique. Sélection de texte, ils le font tous, indenter l'ensemble des lignes sélectionnées, il doit pas y en avoir beaucoup qui savent pas faire.

Utiliser un IDE est une aide précieuse, mais il ne faut absolument pas se baser dessus. D'ailleurs, pour en revenir au sujet initial, apprendre une langage avec un IDE est une erreur : un éditeur avec coloration syntaxique fait l'affaire.

De toute façon, se servir de l'indentation comme délimiteur de bloc est une absurdité.

1/ le HS est bien souvent précisé dans le titre, celui qui veut passer son chemin le peut.
2/ Pour les élections européennes :
A/ une grande partie des contributeurs sont européens donc concernés
B/ Le Logiciel Libre, les débats passés ou actuels (TAFTA, ACTA, …) font que le sujet n'est pas si HS que ça.
3/ Et encore, je n'ai pas parlé de ça

Quand j'ai l'impression que le gouvernement soutient une politique guerroyante ridiculement dangereuse, je crois que j'ai le droit d'interroger les moules pour avoir leur avis, et des compléments d'information.

1/ Précise le HS, avec un titre un peu plus explicite
2/ Interroge sur un site plus approprié
3/ on n'est pas sur politique.fr ici. Vas sur un site plus approprié.

C'est à peine exagéré :). Sinon, je considère que ce n'est pas à l'IDE de pallier ce genre de problème. Idéalement, notepad.exe devrait suffire. S'il faut un IDE sophistiqué ou spécifique au langage, c'est que le langage a un problème.

Quel est le rapport avec linux, les logiciels libres, ou le monde logiciel en général ?

J'ai pas spécialement de problèmes, suffit de mettre sa souris ou son curseur sur la colonne dont tu veux repérer la fin et de faire défiler le texte vers le bas jusqu'au moment ou tu retrouves la bonne colonne de texte remplie.

Encore faut-il être dans un environnement graphique ce qui n'est pas toujours le cas : il ne faut pas oublier qu'il existe des tas d'environnements "hostiles".

Sinon faire le parsage du code pour retrouver le bon marqueur de fin c'est assez pénible aussi sans les repères visuels d'indentation, à supposer que ce soit indenté correctement.

C'est pour ça que je veux les deux : indentation forcée + marqueur de fin.

Hein ? je répète : soit un bout de code du genre :

 def truc (param):
        machin()
         ... 
        if (.....):
            ... 
            ..
        else: 
            if ( ... ) :
               while (condition) : 
                  if (...):
                      ....
                  else:
                      ...

Si je veux reprendre la partie située sous le premier else pour en faire une fonction, je vais devoir décaler l'indentation. Et à un moment donné, je risque de me perdre dans l'indentation. Avec un bloc défini par un marqueur de fin, j'ai un autre repère qui me permet de savoir ou commence et ou s'arrête mon bloc lorsque je retravaille du code. En ruby, j'ai moins de mal. Je répète : obliger à indenter, je trouve ça bien pour la lisibilité, par contre je trouve ça insuffisant. Il manque un marqueur de fin de bloc.

Ou tu crashes jamais tes progs C/C++ compilés :-?

Jamais !!!!

Alors là, je vous arrête tout de suite : C n'a rien à voir avec un quelconque langage d'assemblage.

J'exagère un peu en parlant d'assembleur évolué (car il y a pas mal d'abstractions en C, justement pour permettre la portabilité), mais le C reste un langage très bas niveau. En théorie, dans les normes, il n'y a effectivement pas d'accès aux registres : en pratique c'est possible, voire indispensable d'y accéder pour les programmes bas niveau. Personnellement je ne vois pas le C comme un langage de haut niveau (d'ou ma qualification d' "assembleur amélioré").

Un système de type

Tu veux dire qu'il n'y a pas de type en assembleur ? C'est faux.

La déclaration de types complexes, récursifs

La définition de fonctions
Tu peux déclarer des sous-programmes en assembleur : ce ne sont pas des fonctions à proprement parler, mais ça fait parfaitement l'affaire.

Une pile (peut être qu'il y a des assembleur qui en proposent, mais rien de courant)

C'est justement une des caractéristiques intéressantes de l'assembleur : la pile n'est pas "magique" : tu dois te soucier de sa taille. C'est la même chose en C, sauf que c'est moins évident parce qu'il y a une gestion automatique. Celà dit, la gestion de la pile n'est pas du ressort du langage mais de l'OS, a moins de programmer à bas niveau sans OS.

Tu peux déclarer des types complexes avec les assembleurs récents. Récursifs, par contre je ne sais pas.

Sinon tout ce que tu cites sont des abstractions, qui ne sont pas forcément plus simple que les concepts sous-jacents en assembleur.

Si tu rajoutes une condition et que ça touche l'indentation de plusieurs dixaines de lignes de code, c'est qu'il faut que tu apprennes à mieux séparer ton code en fonction.

Bien souvent, ce n'est pas ton code que tu dois modifier mais le code d'un pseudo-développeur, qui a fait un peu de python dans sa vie et qui est persuadé de faire du code propre parce qu'il utilise Python et que son code est bien indenté. Et tu retrouves justement ce genre de problématique lorsque tu récupères un ou plusieurs blocs de code pour les déporter dans une fonction parce que le code devient ingérable, parce qu'il n'a pas été bien écrit, bien décomposé en fonction. Dernièrement j'ai eu entre les mains un bout de code ou le développeur faisait plein de choses différentes dans la même fonction. Le plus drole, c'est que le code traitait les problématiques sans ordre logique, avec des threads dans tous les sens (donc interblocages …).

Personnellement, je ne commence rien en Python, j'utilise autre chose : mais je suis obligé de toucher à dees programmes python qui ne sont pas les miens. Et en général, ce n'est pas beau à voir.

La règle qui dit qu'on déclare une variable au plus près de sa première utilisation et dans la portée minimum est maintenant une des règles fondamentales de la programmation dans n'importe quel langage

En quoi Pascal transgresse-t-il cette règle ?

La portée minimum d'une variable est la fonction/procédure, et tu la déclares au plus près de sa première utilisation dans la portée minimum, soit au début de la fonction. Si tu abordes un autre langage ou tu peux faire plus fin, tu le précises … Il n'y a pas de contradiction : c'est comme ça que j'ai appris.

C'est aussi important que le code en lui-même et c'est souvent plus difficile d'ailleurs.

C'est le genre de choses que j'éviterais d'aborder dans un premier temps. Et maintenant je me souviens pourquoi je n'avais pas traité la différence entier/décimal : la programmation avec des décimaux est compliquée. Et balancer toutes ces problématiques d'un coup risque de poser problème. Personnellement, lorsque j'ai appris le C, j'ai été un peu noyé sur plein de notions assez abstraites, mais comme l'informatique était mon métier, ce n'est pas grave : j'ai eu du temps pour comprendre (il m'a fallu environs 1 semestre pour assimiler les notions de base en C ). Dans le cas cité par l'auteur du journal, je ne pense pas que ce soit popssible d'aborder les choses de la même façon.

Donc des scientifiques qui en continueront pas à faire de la programmation, ça n'existe pas. Ils continueront, quoi qu'il arrive. Donc autant commencer sur de bonnes bases.

Oui, mais il ne faut pas introduire trop de concepts à la fois pour éviter de noyer sous une masse d'information imbitable. C'est pour ça qu'à mon avis, se limiter à 1 seul langage pour apprendre la programmation, ce n'est pas une bonne idée.

Quelque part, je rejoins le point de vue de je ne sais plus qui plus bas qui parlait d'assembleur. Programmer sans avoir de notion sur la façon dont fonctionnent les processeurs, leur façon d'adresser la mémoire et la façon de représenter les données en interne est difficile. Faut-il aller jusqu'à l'assembleur ? Difficile à dire, parce qu'on ne peut comprendre certaines problématiques de la programmation que si l'on sait ce qui se passe à bas niveau. Mais d'un autre côté, pour des personnes n'ayant pas l'informatique comme enseignement principal, c'est difficile de placer le curseur au bon endroit pour ne pas les dégouter.

Ah bon, pourquoi avoir inventé le C alors ?

Pour la portabilité : porter Unix sur d'autres archis que le PDP11 me semble-t-il. A vérifier.

Sinon le C n'est qu'un "assembleur évolué".Et j'ai eu plus de al à appréhendre le C que l'assembleur.

Absolument rien. Mais le fait que l'indentation définisse la structure de bloc en python rend le code plus concis et facilite la lecture. L'algorithme transparaît. On peut évidemment pinailler sur ce sujet mais c'est un fait. Un code plus concis est plus simple à comprendre.

… jusqu'au jour ou tu dois modifier du que tu as récupéré, en ajoutant une condition quelque part, et que tu n'as qu'un vi sous la main. Tu as 99 chances sur 100 de te vautrer et d'oublier une indentation quelque part, ou d'en avoir une en trop, et de passer des heures à trouver ou elle est (parce que l'interpreteur te met l'erreur à la fin de ton prog ou de ta classe).

Obliger à indenter, c'est bien. Se servir de l'indentation comme identification de bloc, c'est idiot.

Qu'un langage interprété est une évidence pour l'apprentissage.

Faux. L'un ou l'autre ne change rien. Un langage interprété est aussi compilé, mais ça se voit pas . sinon pour le reste je suis assez d'accord avec toi : apprendre la programmation avec un langage comme C++ est une aberration : on risque de perdre la moitié des élèves.

Il se traîne des trucs qui ne sont plus d'actualité, genre le fait de devoir déclarer ses variables à part, au début.

Est-ce vraiment si important que ça lorsqu'on initie quelqu'un à la programmation ? Tu n'aurais pas d'autres éléments ?

Tour d'ivoire ? Je ne suis pas pédagogue, je suis enseignant, je suis au contact direct des étudiants, je vois sur quoi ils ont des difficultés et ce qui est plus facile à apprendre pour eux, avec des gammes de niveaux très étendues (j'ai des étudiants qui ne comprennent pas le principe d'une boucle while). Alors je crois que la tour d'ivoire, elle est loin.

Désolé pour cette façon de m'exprimer, je me rends compte que ma façon de m'exprimer ait pu t'offenser, ce n'était pas le but. Celà dit j'ai quand même un peu de mal avec "e ne suis pas pédagogue, je suis enseignant". Un enseignant ne doit-il pas être pédagogue ?

Comment tu fais comprendre la division entière avec un seul type numérique ? Il y a une grosse quantité de problème qui nécessite de faire la différence entre entiers et réels, et c'est important de le faire dès le début. La programmation, c'est autant savoir choisir les bons types que de choisir les bons algorithmes.

Si tu introduis ça au début, pur des personnes qui ne continueront probablement pas à faire de la programmation, tu les dégoutes. Maintenant, j'ai peut-âtre été trop restrictif dans les types de base, et je t'accorde que différencier décimal/entier serait prebablement pertinent. Comme tu parlais de C/C++, j'avais à lesprit la totalité des types C/CPP (int, short , long, float, double, etc ….) qui sont difficiles à appréhender quand tu commences à programmer.

C'est quoi que tu ne comprends pas dans «sous-ensemble» ? Évidemment qu'on ne va pas leur montrer le template metaprogramming ! On va se contenter, je répète, des types de bases

Déjà les types de base en C++ sont déjà trop complexes :

int  : contient un entier de taille normale, positif ou négatif.
short int  : contient un entier de petite taille, positif ou négatif.
long int  : contient un entier de grande taille (32 bits), positif ou négatif.
long long int  : contient un entier de plus grande taille (64 bits), positif ou négatif.
unsigned int  : contient un entier de taille normale, positif ou nul.
unsigned short int  : contient un entier de petite taille, positif ou nul.
unsigned long int  : contient un entier de grande taille (32 bits), positif ou nul.
unsigned long long int  : contient un entier de plus grande taille (64 bits), positif ou nul.

Il y a quoi de difficile là dedans ? Rien.

Pour toi, rien. Pour des personnes pour qui la programmation n'est qu'un sujet qu'ils vont aborder sans continuer : tout. Et je suis quasiment convaincu qu'à un moment tu vas devoir sortir de ton sous-ensemble. C++ est un langage complexe, sans même aborder les templates. Par contre je le verrais bien comme second langage, lorsque les notions de base algorithmiques seraient acquises.

PArce qu'il n'yen a pas besoin : ça marche très bien avec peu de contributeurs … CQFD.

c'est maintenable par des personnes qui ne connaissent pas python !

Quelle idée stupide !!! Te viendrait-il à l'idée de faire maintenir ta voiture par quelqu'un qui ne connait pas la mécanique automobile ?

Et bien oui, je suis d'accord, je suis sorti dès le début. Je pense d'ailleurs que le Java n'est pas un bon langage pour l'apprentissage, donc vraiment, ce n'était pas l'objectif. Seule la fin de mon message concerne le sujet initial.

+1 pour cette précision qui permet de remettre dans le bon contexte tes propos.

Je sais mais c'est stupide de devoir passer par cette méthode "spéciale" entourée de __

Le fait qu'il soit très utilisé renforce l'intérêt d'un langage :

En théorie, c'est vrai mais en pratique, si je prends le cas python :

• Communauté pour pouvoir t'aider

Communauté qui passe son temps à t'engueuler parce que tu veux faire les choses d'une façon qui n'est pas "la bonne façon", qui ne répond pas à ton besoin mais à côté.

• Beaucoup de tutos et autres docs

Dans le cas de python, c'est vrai. Mais en pratique, il vaut mieux un ou deux bon bouquins qu'un tas d'infos dispersées partout sur le web. Par exemple, si on parle du Javascript, on trouve plein de tutos qui au final n'apprennent pas grand chose parce que ne font que survoler les choses. Beaucoup de bruit.

• Pleins de libs pour t'éviter de devoir réinventer la roue 36 milles fois

Pour apprendre, je vois plutôt ça comme un frein …

• Outillage dédié au langage

Pour apprendre, pas besoin de plein d'outils : un éditeur de texte, un interprêteur ou un compilateur, et zou. Ah si : l'éditeur devrait si possible permettre d'accéder à une aide en ligne, mais pas plus. Mais là je parle du cas ou l'on veut apprendre. Ensuite on peut passer à des IDE plus sophistiqués.

Un exemple classique est le Java. C'est un langage pas trop mal mais s'il est si souvent utilisé aujourd'hui c'est parce qu'il est beaucoup utilisé (ayé, me suis fork-bombé le cerveau). Ce que je veux dire par là c'est qu'on va souvent choisir le langage parce qu'on sait que :
[ … ]

Là tu sors du cadre initial : l'apprentissage. Pour apprendre tu te fiches royalement qu'il y ait plein de libs, Je doute également que quelqu'un reprenne ton projet de Hello World, de tri à bulle, ou de calcul de suite de Fibonacci. Certes tu pourras demander de l'aide, et c'est le seul point avantageux que je vois dans ceux que tu cites.

Franchement, dans les réponses que je lis, le plus souvent c'est [mon langage préféré] qui revient le plus souvent. Avec la supposition non-dite : s'ils commencent par ça, ils continueront

Faux : je n'ai pas cité mon langage préféré.

Mon avis, c'est qu'il faut bannir tout langage à typage dynamique. Pourquoi ? Parce que choisir le bon type, ça fait partie de l'apprentissage en informatique,

Ca c'est bien une idée de prof dans sa tour d'ivoire. Le typage, c'est un concept difficile à apprendre pour "des étudiants qui ne se destinent pas forcément à l'informatique". Le typage est une notion difficile que la majorité ddes personnes ne faisant pas d'informatique ne comprend pas.

Alors certes, je ne dis pas qu'il ne faut pas l'apprendre, mais il faut rester simple : par exemple, un type numérique et un type texte ça suffit pour apprendre à programmer. Et je ne connais pas vraiment de langage qui ait un typage aussi simple (le basic dans mes souvenirs ou le type texte était suffixé par un $ dans le nom de la variable ?)

Autre inconvénient à mon sens : le fait que les objets dans ces langages soient le plus souvent accédés via des références complexifie la compréhension

Là je suis d'accord avec toi : ça c'est une plaie (va expliquer pourquoi par exemple lorsque je modifie le tableau a, b est aussi modifié : en fait quand on regarde un peu plus haut, on voit qu'à un moment, il y a eu un truc du genre a = b ).

Après, on peut prendre le problème à l'envers : de quelles fonctionnalités a-t-on besoin ? Pas grand chose au final : les structures de contrôle usuelles, les types de bases, les entrées-sorties.

Qu'entends-tu par "entrées-sorties" ?

Pascal (puisque c'est ce que j'ai mis dans le titre) avait l'avantage d'offrir tout ça de manière simple et efficace. Malheureusement, il est un peu daté maintenant.

C'est à dire ? Même s'il n'est pas beaucoup utilisé, ça n'enlève rien à ses qualités pédagogiques non ?

C++. Pas tout C++ mais le sous-ensemble de C++ qui permet ce que j'ai décrit précédemment.

Tu délires là non ? C++ pour apprendre ? Il y a bien plus simple aujourd'hui. Tu veux dégouter tes étudiants de la programmation ?

De toute façon, une fois ces bases acquises, généralement, on change de langage et on passe à d'autres langages pour apprendre d'autres paradigmes et d'autres algorithmes, donc le premier langage importe assez peu au final, il ne dure pas très longtemps.

Personnellement ,j'ai appris la programmation avec le BASIC : tu peux lui reprocher touis les défauts que tu veux, mais il y avait au moins les critères que tu citais : un typage simple, structures de controle, et enttrées sorties.

Question : que manque-t-il à Pascal à tes yeux pour un premier langage

Si on reste dans le contexte "Premier langage pour apprendre la programmation", ie le sujet du 'nal, ça a du sens de chercher un langage plus répandu.

Je ne vois pas le rapport : ce n'est pas parce qu'un langage est répandu qu'il va faciliter l'apprentissage de la programmation. A une époque, le C était l'uin des langages les plus répandu, mais pas forcément le meilleur pour apprendre la programmation.

Je dirai que son principal inconvénient est d'être dynamiquement typé: il y a pas mal de cas (spécialement quand tu es débutant d'ailleurs!) ou le compilateur aurait pu te signaler des erreurs qui ne se voient qu'à l'exécution en Python..

Ce n'est pas forcément un inconvénient, surtout pour un premier langage.

il y a pas mal de cas (spécialement quand tu es débutant d'ailleurs!) ou le compilateur aurait pu te signaler des erreurs qui ne se voient qu'à l'exécution en Python

Ca permet d'apprendre aux débutants à automatiser ses tests.