Discussion :

[naquadah]

Je trouve absurde de se plaindre que la programmation est trop difficile, car elle pourrait l'être bien plus si les créateurs des langages de programmations, que ce journaliste bafoue délibérément, n'avaient pas créé ces langages (qu'il bafoue aussi avec joie), car s'il a du mal avec de l'Objective C, je crois qu'il pleurerait devant un programme en Assembleur, voire pire, en binaire.

C'est fou de voir à quel point les gens attendent des programmeurs, ingénieurs et informaticiens qu'ils leur facilitent la tâche, mais l'informatique est un domaine incroyablement vaste et complexe, pas à la portée de tous, et alors?

Ce journaliste a-t-il un complexe d'infériorité devant les développeurs d'applications Iphone, ou bien devant les programmeurs en général?

Il faut arrêter un peu, la programmation, CE N'EST PAS DE LA CUISINE, ça ne l'a jamais été, et ça ne le sera sans doute jamais. Il faut connaître un minimum le fonctionnement de la machine pour programmer, quel que soit le langage, vous n'allez pas écrire dans bloc note:"fais moi une application, avec pleins de petits trucs marrants, etc...". Puis appuyer sur Enter, et obtenir un petit fichier .exe tout frais. Non mais je rêve!

En plus, il existe des tas de langages informatiques de haut niveau, simples, adaptés aux débutants, et bien que je crois qu'ils ne sont pas portables sur Iphone, je crois que pour commencer à programmer, il vaut mieux commencer avec un ordinateur, tout simplement, plutôt que de se lancer dans des projets iréalisables et inutiles, pour dénoncer un problème INEXISTANT.

De plus, je crois qu'il est simple de rejeter la faute sur des langages de programmation, sans même les connaître, pourtant, chaque langage, quoiqu'on en dise, a son intérêt, certes ses points faibles, mais aussi ses atouts, et ce journaliste semble plutôt motivé par une absence totale de bonne foie, et plutôt que d'admettre qu'il n'a pas les capacités intellectuelles pour aborder la programmation, il dénonce des langages "trop complexes". Le pauvre!

Pour finir, je crois qu'il faut souligner le fait qu' AUNCUN INFORMATICIEN NE DOIT QUOIQUE CE SOIT AUX GENS. Il n'est nul part écrit que les informaticiens se doivent de faciliter les langages pour en rendre plus facile l'accès à ceux qui n'ont pas les capacités intellectuelles qui vont de pair avec la programmation. Les langages sont conçus et optimisés pour des programmeurs qui veulent vraiment se donner les moyens de programmer, pas pour des chèvres en informatiques.

[negstek]

Je pense qu'il est important de constater qu'il y a un engouement du public pour les technologies embarquées et que les gens veulent maintenant "programmer" des petites application sans pour autant devenir des développeurs chevronnés. Vu qu'il y a une forte demande celui qui réalisera un langage simplifié de très haut niveau avec un IDE embarqué se fera pas mal de beurre avec cette appli. Je crois qu'il y en a une pour android mais j'ai pas retrouvé le nom. Sinon est-ce que quelqu'un fait du WinDev, est-ce que ça pourrait ressembler au genre de facilité de langage dont parlait ce journaliste ?

[negstek]

J'ai trouvé une appli du style dont je parle pour android à savoir:

[ame="http://www.youtube.com/watch?v=8ADwPLSFeY8&feature=player_embedded"]google app inventor[/ame]

&&

[Suryavarman]

Je pense que ce journaliste ne connais pas les logiciels d'édition avec des boi-boites à lier entre elles.

Le jeux vidéo, les GUI... ont ce besoin d'outils RAD.

Les développeurs sur IPhones ont ils ce besoin ? A parement oui, donc c'est pas la peine de jeter un pavé dans la marre comme ça. Il a cas exprimer son besoin à Apple ou à d'autres. Et si son besoin est l'expression du marché alors il aura peut être son outil de développement.

Par contre oui la programmation à quelque chose d'assez lourd. C'est la mise en place de tout les outils. Mais je pense pas que ça soit la plus lourde à ce niveau là si on compare à d'autres métiers.
Combien de fois j'ai hurler pour compiler boost sous windows pour mingw et VC90... Merci CMAke car Jam j'y suis jamais arrivé. Combien de temps j'ai du passer pour que l'ensemble de mes librairies soient compilées et en plus d'une manière propre et uniforme. Dans mes projets j'ai du passer plus de la moitié du temps à mettre en place les outils. C'est peut être sur ça que le journaliste est tomber. Car dans l'ensemble une fois les outils installer, coder est relativement simple et la complexité est fonction du plaisir.

Mais même cette lourdeur trouve un écho. Depuis quelques années je constate que les projets sont de plus en plus "normés". Ils sont munis d'une forge de travail, un outil de génération de solution, cross plateforme.... Tout cela tend vers le désir d'offrir un outil non contraignant au développeur.

Alors oui ça se complexifie mais pour le plaisir des développeurs et en parallèle l'accès se simplifie. Mais il reste encore beaucoup de chemin.

[sylafrs]

Certes, la cuisine c'est facile..
..mais créer la recette l'est beaucoup moins !

Je trouve que lire un code tout fait c'est effectivement simple...

[ernestrenan]

"L'autre jour j'ai essayé de construire une maison parce que c'est vraiment cool d'avoir une maison et puis l'avoir faite soi même ça pete. Alors j'ai commencé .... mais c'est trop dur. Les physiciens et chimistes devraient penser à changer leurs équations parce qu'à un époque où tout le monde vit dans une maison c'est pas normal qu'on puisse se confronter à des obstacles qui nous empêchent d'en construire une. L'autre jour j’étais à une agence immobilière : il suffisait de choisir sa maison et il ne restait plus qu'à la décorer et la meubler. Alors pourquoi c'est pas aussi facile que ça d'en construire une. En plus c'est bizarre parce que j'étais vraiment bon en lego et mecano quand j’étais gamin. C'est bien la preuve que les scientifiques font exprès de faire des lois compliquées...
Alors toutes ces théories dans les diverses branches de la physique ne pourraient-elles pas être condensé en une seule et unique loi qui nous faciliterait tous la vie. Je crois que si mais malheureusement c'est bien au delà de mes capacités...".
Cet article me choque autant que si ce pseudo journaliste avait écrit ça. C'est du délire complet. Si on pouvait avoir des baguettes magiques et dire "abracadra" pour avoir un code fonctionnelle, stable et sure ça se saurait !
(voilà au moins la preuve qu'un journaliste ne peut pas s'improviser développeur mais que la réciproque n'est pas vraie )

[negstek]

Sinon est-ce que quelqu'un fait du WinDev, est-ce que ça pourrait ressembler au genre de facilité de langage dont parlait ce journaliste ?

Alors, personne ?

[kdmbella]

Alors, personne ?

j'ai des confrères qui développent sous Windev et croyer moi c'est pas qu'une histoire de clic il faut effectivement avoir de la suite dans les idées et pour faire des adaptations, car une application généré ne sera jamais parfaitement adapter à vos besoin, il faut a certain moment personnaliser le code et c'est une autre paire de manche !

[Richard Trigaux]

Je crois, et mon expérience confirme, qu'il y a une part de complexité inévitable, mais aussi beaucoup de complexité ajoutée (à dessein pourrions-nous penser).

Exemple de complexité nécessaire: les types de variables. Vu la variété des données à manipuler, il y en a forcément de nombreux... encore qu'il n'est pas sorcier d'afficher la liste dans une page d'info ou de tutoriel

exemple de complexité inutile: m'essayant à C++ version microsoft, je me retrouve avec des types de données spéciaux, dont il est impossible de trouver la nature ni la conversion...

exemple ce complexité visiblement ajoutée à dessein: la base de registre Microsoft, où les données utiles concernant chaque application sont dispatchées entre quatre catégories totalement non-pertinentes, et cachées par des noms abscons... et gare, la moindre erreur peut planter la machine... Mais le site porno du coin a le droit de modifier cette base de registre!!!

[DonQuiche]

Exemple de complexité nécessaire: les types de variables. Vu la variété des données à manipuler, il y en a forcément de nombreux... encore qu'il n'est pas sorcier d'afficher la liste dans une page d'info ou de tutoriel.

Toi, tu ne comprends pas les langages dont tu te sers. ^^

Laisse-moi t'expliquer : si tu écris "a + b" en C, selon que a et b sont des entiers ou des réels 32 bits, le compilateur doit émettre des instructions assembleur différents. Dans un cas il devra stocker les valeurs dans les registres réels, dans l'autre cas elles le seront dans les registres entiers, et l'instruction d'addition sera elle aussi différente dans chaque cas.

Et comment font les langages à typage faible ? Et bien, ils ajoutent des trucs du genre "si type == entier32 alors faire (int)a + (int)b sinon si type ==..." Ce qui est évidemment beaucoup plus lent.

EDIT : Légère correction par rapport au fait que les registres entiers et réels sont distincts.

exemple de complexité inutile: m'essayant à C++ version microsoft, je me retrouve avec des types de données spéciaux, dont il est impossible de trouver la nature ni la conversion...

Et tu ne manqueras pas de comprendre un jour à quoi ils servent, même si ce n'est pas le cas aujourd'hui. Rassure-toi, MS ne les a pas ajoutés pour te compliquer la vie (et la leur).

exemple ce complexité visiblement ajoutée à dessein: la base de registre Microsoft, où les données utiles concernant chaque application sont dispatchées entre quatre catégories totalement non-pertinentes, et cachées par des noms abscons... et gare, la moindre erreur peut planter la machine... Mais le site porno du coin a le droit de modifier cette base de registre!!!

CurrentUser, LocalMachine, Users, c'est vraiment abscons ? Et ça ne te semble pas nécessaire comme distinction ?



Les seules complexités superflues sont celles héritées du passé (ou les éventuelles erreurs de conception). Mais on les conserve par souci de compatibilité, afin que les dévs du monde entier n'aient pas à réécrire leurs applis à chaque changement de matériel.

[Bluedeep]

Je crois, et mon expérience confirme,

Vu le salmigondis que constitue le reste de votre poste, on est en droit de s'interroger sur "[votre] expérience [qui] confirme".

[Richard Trigaux]

Hmmm... j'ai bien l'impression qu'il y a un certain corporatisme des codeurs, afin de paraître indispensables :-)

[Richard Trigaux]

Prenons un exemple, le typage des variables.

Pour un codeur débutant, les langages à typage faible, ou à typage automatique, parraissent sympatiques, car "plus simples". Toutefois, on s'aperçoit vite que les typages faibles produisent des erreurs qui sont difficiles à trouver... surtout quand on apprend.

Ainsi le typage fort (déclaration systématique du type de variabe) paraît plus compliqué au débutant, mais il économise certains problèmes, et finalement on l'apprend vite.

Par contre le genre de problème sur lequel je suis tombé en C++ microsoft, est que pour ouvrir un fichier, le paramètre nom_du_fichier a pour type LPCTSTR, tandis que pour écrire dans un fichier, le même paramètre a pour type un autre truc du même genre (désolé je n'ai pas retrouvé) au lieu d'utiliser des chaînes comme en C standard. En plus, microsoft oblige, pas moyen de googler une documentation correcte expliquant ces types... on est sensé savoir de naissance.

Dans ces conditions, on a clairement une complexité ajoutée inutilement (ou si peu d'utilité), qui en plus rend le fichier non-portable. Bien sûr, Microsoft nous fournit gratuitement un outil de développement C++, mais ce n'est pas par gentillesse, c'est pour qu'ensuite nous soyons obligé de rester avec eux...

[Richard Trigaux]

Bluedeep:

Vu le salmigondis que constitue le reste de votre poste, on est en droit de s'interroger sur "[votre] expérience [qui] confirme".

Désolé, ceci est un forum d'informatique... d'où quelques termes un peu spécialisés :-)

[gl]

Pour un codeur débutant, les langages à typage faible, ou à typage automatique

Qu'appelles tu typage automatique ? Typage dynamique, inférence de type ou autre ?

Dans les deux premiers cas (typage dynamique ou inférence de type), ce n'est pas forcément contradictoire avec un typage fort, ce sont des notions orthogonales.

Ainsi le typage fort (déclaration systématique du type de variabe)

Même remarque, il n'est pas du tout impossible de faire du typage fort avec de l'inférence de type (ni du typage faible avec du typage déclaratif d'ailleurs).

[DonQuiche]

@Richard Trigaux
A nouveau, tu lâches un gros troll simplement parce que tu ne sais pas !

Leçon d'histoire donc... Il fut un temps que les moins de vingt ans ne peuvent pas connaître où Unicode n'existait pas, ou bien était encore jeune mais peu répandu et gourmand en ressources (16 octets par caractère, mon dieu, c'était la fin du monde). A l'époque on utilisait (comme tu le fais encore, à tort) des char* et ces applications ne pouvaient pas afficher de textes chinois, japonais, etc.

Puis Microsoft lança Windows 3.1 et les premières versions de NT. Unicode venait alors d'apparaître (le développement de Windows 3.1 a débuté très peu de temps après la normalisation d'Unicode). Et MS se trouva bien embêté : beaucoup de développeurs ne voudraient pas d'Unicode, trop gourmand dans un monde où 512ko de RAM faisait saliver et parce qu'ils possédaient une base de code existant taillée pour l'ANSI. Les développeurs de Microsoft réalisèrent donc qu'ils devaient fournir à la fois un support pour les chaînes normales, s'appuyant sur des pages de code (char*) et un support pour les chaînes unicodes (wchar_t*). Comme il est fastidieux de lire une API où toutes les chaînes sont du type "unsigned wchar_t*", ils créèrent deux raccourcis : LPSTR pour unsigned char* et LPWSTR pour unsigned wchar_t*

Avant de continuer, une précision : à l'époque, horreur, Intellisense n'existait pas, on se contentait d'éditeurs rudimentaires, voire du "notepad" ou de "edit.com". Oui, je sais, ça semble vraiment effrayant mais on y arrivait. Et donc il était impossible de vérifier en vitesse à quel type correspondait un raccourci, un membre, une variable. Si bien qu'on utilisait beaucoup la notation hongroise qui consiste en l'ajout de préfixes précisant les types impliqués. Donc LP pour Long Pointer (à l'époque on utilisait encore des pointeurs 16-bits dans certains cas, plus rapides et notés P, et les long pointers étaient des pointeurs 32-bits). W pour word (16-bits, le poids d'un caractère UTF-16).

Tout ceci étant expliqué, maintenant qu'on a bien compris pourquoi MS avait de très bonnes raisons d'introduire LPSTR et LPWSTR, et de les appeler ainsi, voyons LPTSTR. Et bien, LPTSTR est défini soit comme LPSTR, soit comme LPWSTR : tout dépend si tu as ou non défini la constante UNICODE avant de charger winnt.h. Et cette simple petite modification a permis à MS non seulement d'offrir une unique API pour le support des deux types de caractère (inutile de faire à chaque fois deux variantes d'une fonction, l'une pour caractères 8 bits et l'autre pour caractères 16 bits avec un suffixe à la noix) mais aussi de faciliter le portage de toutes les applis windows vers Unicode puisqu'il était clair que c'était l'avenir : en utilisant LPTSTR partout, les développeurs n'auraient qu'à rajouter un simple "#define UNICODE" pour basculer tout l'appli vers Unicode !

Quant à LPCTSTR, et bien le C veut bien sûr dire constante et désigne soit un "const unsigned char*" soit un "const unsigned wchar_t*. Comme tu le vois, tout ceci a permis de simplifier la vie des codeurs. Evidemment, aujourd'hui tout ça semble un peu lourd, comme l'ensemble du C/C++ d'ailleurs, mais on ne peut pas revenir en arrière sans briser la compatibilité.


Tout ceci étant dit, quelques remarques :
* Charles Petzold a écrit de merveilleux livres sur la programmation Win32 qui font référence. Leur lecture est plus que conseillée vu l'âge et la dimension de cette plateforme.
* Hier le typage fort ajoutait inutilement de la complexité d'après toi. Aujourd'hui, tu nous dis qu'il simplifie le boulot des codeurs. Il faudrait que tu te décides.
* J'ai vérifié ce que donnait une recherche Google pour LPCTSTR : le troisième résultat est celui-ci. Tu ne voudrais pas y mettre un peu du tien ?
* Ne t'inquiète pas pour Bluedeep, il en connaît douze rayons de plus que toi. Par salmigondis il désignait plutôt un tissu d'idioties. On lui donnera difficilement tort.
* Quand on ne sait pas, mieux vaut poliment demander que de lâcher des gros trolls et passer pour un idiot grossier.

[Richard Trigaux]

Qu'appelles tu typage automatique ? Typage dynamique, inférence de type ou autre ?
Dans les deux premiers cas (typage dynamique ou inférence de type), ce n'est pas forcément contradictoire avec un typage fort, ce sont des notions orthogonales.
Même remarque, il n'est pas du tout impossible de faire du typage fort avec de l'inférence de type (ni du typage faible avec du typage déclaratif d'ailleurs).

Merci de ces précisions. Par "typage faible" j'entendais que le programment n'a pas besoin de préciser le type de la variable, alors que dans un "typage fort" ne pas préciser le type renvoie systématiquement un message d'erreur. Je ne voulais pas parler de la façon doont ce typage est calculé par le compilateur.

Evidemment, un codeur débutant trouvera plus simple de ne pas avoir à se soucier de types de variables, une notion peu intuitive pour lui. Mais, après quelques galères, il éprouvera vite le besoin de déclarer lui-même le type de ses variables, ou au moins d'avoir des règles de typage claires. Le typage obligatoire est donc un bon exemple de complexité nécessaires.

[gwinyam]

Le typage faible est une calamité pour les débutants. Il les aide peut être en leur permettant de se concentrer sur l'algorithmique plutôt que sur des "futilités" de typage. Mais ce sont justement ces subtilités qui font toute la complexité des langages et leur compréhension qui permet de se prétendre compétent ou non.

Exemple :
Combien de fois j'ai vu des développeurs me soutenir que Javascript convertissait automatiquement son entier en chaîne ou en float selon le besoin à l'instar de PHP. Ceci est vrai mais aussi particulièrement faux. Puisqu'il n'existe pas d'entier en Javascript. Ils existent visuellement parce que le langage tolère de ne pas mettre de virgule sur les nombres, mais ils n'existent pas d'entier à proprement parler. Tous les nombres en JS sont des flottants à double précision. Savoir ça ne change pas la vie du programmeur mais permet de comprendre beaucoup mieux comment fonctionne le langage et évite de faire des tas de salo**ries.

Comme pour tout, le développement est un métier. On ne s'improvise pas du jour au lendemain, c'est notamment l'expérience qui fait du développeur ce qu'il est, et non sa bonne volonté.

[Richard Trigaux]

Le typage faible est une calamité pour les débutants...

Tout à fait d'accord.

Je pensais effectivement au Javascript, un langage "simple" mais que je n'aime pas, à cause justement de ce flou sur les types. Un problème similaire se trouve en Python, où il fait écrire 2.0 au lieu de 2, si on veut que notre résultat soit en virgule flottante. C'est un beau piège à débutants, et comprendre pourquoi prend plus de temps que d'apprendre à écrire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

float MaVariable = 2

Ce que je dirais, ce serait, pourquoi pas, de faire tout le monde pareil. On a une douzaine de types de base, char, int, float, etc. qui sont les mêmes pour tous les langages. Pourquoi ne pas effectivement les écrire tous pareils? Ce serait une simplification réelle (éliminer des complexités inutiles, ou d'avoir à apprendre plusieurs fois la même chose). A la limite, on arriverait, au fil des évolutions, à un langage unique, simple à apprendre pour les applications générales, mais qui intégrerait sous forme de fonctions les particularités des langages spécialisés comme le LSL, le Lisp, etc.

Ainsi l'idée de Chris Tompkins (le journaliste dont nous débatons) deviendrait petit à petit réalité. Actuellement, le PHP est un des langages qui se rapprochent le mieux de ce cas (encore qu'il y ait quelques arrachages de cheveux avec les ===).

[gwinyam]

Ce que je dirais, ce serait, pourquoi pas, de faire tout le monde pareil. On a une douzaine de types de base, char, int, float, etc. qui sont les mêmes pour tous les langages. Pourquoi ne pas effectivement les écrire tous pareils?

Et perdre tout intérêt de chaque langage ? Tu te rends compte de ce que ça veut dire ?

J'ai peut-être pris un exemple trop simpliste en fait. La gestion du typage et même les différents types sont des caractéristiques propres à chaque langage et il y a une raison. Pas pour em**rder le néophyte et faire briller le crâne de ceux qui maîtrisent mais pour permettre une optimisation de chaque langage pour chaque usage spécifique.

Il n'existe pas de meilleurs langages que d'autre d'un point de vue général, tout dépend de l'usage que tu en as. Et c'est chacune de ses spécialités de langage qui est déterminé par les spécificités de chaque langage (uh ? je me suis lâché là oO).