Un ancien d'Apple montre un nouveau principe de création
Bret Victor fut un "inventeur d'interfaces humaines" chez Apple de 2007 à 2010, où il travailla notamment sur iOS. Lors de la Canadian University Software Engineering Conference, il fit une présentation d'une heure sur les derniers concepts qu'il a mis au point.
Ceux-ci sont particulièrement intéressants, notamment pour quiconque a déjà développé dans sa vie. Pour Bret Victor, le développement se fait "à l'aveuglette" : on tape du code, on compile, on voit le résultat, et on recommence, au lieu de voir directement les modifications mises en application.
Cela présente deux inconvénients : d'une part nombre de bugs pourraient être évités, et d'autre part le simple fait de pouvoir constater directement les effets des modifications dans le code est en soi-même un excellent moyen d'avoir de nouvelles idées.
Dans cette conférence d'une heure, Bret Victor a donc présenté un outil qui permet de voir directement les effets concrets que peuvent avoir des modification d'un code en JavaScript. Il est ainsi possible de modifier chaque valeur numérique à la souris pour en voir les conséquences dans une fenêtre séparée. Sur un petit jeu, il peut ainsi modifier les paramètres pour les ajuster au pixel près. Mieux encore, son système permet de rejouer la partie qu'il vient de faire à n'importe quel point dans le temps, et même une représentation temporelle montrant toutes les positions du personnage : là encore, les trajectoires affichées sont modifiées rien qu'en ajustant les valeurs numériques de son code, de manière limpide.
Bret Victor souligne une autre incongruité du métier de développeur : en écrivant le code, il faut "jouer à l'ordinateur", c'est à dire imaginer les résultats de ce que l'on écrit, avant de pouvoir les constater de visu. Ceux qui sont les plus doués à ce jeu de l'esprit font partie des meilleurs développeurs, mais pourquoi "jouer à l'ordinateur" quand l'ordinateur lui-même pourrait jouer son propre rôle? Il fait la démonstration d'une fonctionnalité qui permet d'appliquer des valeurs d'exemple à une fonction alors même qu'elle est en cours d'écriture (en l'espèce une recherche par dichotomie), ce qui lui permet de se rendre compte directement des cas de figure qu'il n'a pas géré dans sa fonction et ainsi d'éviter plus facilement des bugs.
Et ce principe peut être décliné à l'infini : il présente par la suite le cas d'un schéma électronique… fonctionnel, c'est à dire simulé par l'ordinateur. Là encore, il fallait imaginer le résultat avant de pouvoir le vérifier dans les faits. Là aussi, il peut modifier les valeurs à la souris et constater directement leurs conséquences, ou surveiller le voltage entre chaque composant et les comparer d'un simple survol de la souris.
Il compare l'approche actuelle de la programmation à sa propre genèse : les cartes perforées. Celles-ci ne prenaient pas en compte le concept d'interactivité, et pour cause, puisqu'il fallait poinçonner ces cartes pour pouvoir entrer la moindre instruction dans un ordinateur, sans même avoir un retour vidéo. Il est donc plus que temps de reléguer cette approche au passé auquel elle appartient.
Enfin, il présente un outil d'animation sur iPad qui offre une approche beaucoup plus intuitive que les outils de Flash, puisqu'il permet de réaliser les animations "aux doigts", en temps réel. Là encore il suit sa philosophie de l'approche directe et du retour en temps réel sur une création dont les résultats sont d'ordinaire présentés en différés.
De ce principe simple, l'utilisation même de nombreux outils pourrait en être bouleversée, offrant une approche directe et intuitive, un énorme gain de temps, et la naissance de nouvelles idées alors même que l'on "joue" divers scénarios sur ces outils.
En s'appuyant sur l'illustre exemple de Larry Tesler, un ingénieur du Palo Alto Research Center de Xerox qui mit un terme aux différents modes de manipulation de texte, inventant au passage le couper-copier-coller (il travailla plus tard sur le Newton chez Apple), Bret Victor va plus loin encore en bâtissant une réflexion au niveau social : le grand mérite de Larry Tesler a été d'identifier et de résoudre un problème qu'il était le seul à voir. Pour tout le monde, les modes faisaient partie de l'informatique et nul n'imaginait qu'il puisse en être autrement, de la même manière qu'Elizabeth Cady Stanton a réalisé que les femmes devraient avoir le droit de vote. Faisant appel à d'autres illustres prédécesseurs tels que Doug Engelbart (lire Une vieille histoire de rongeur), Alan Kay, ou Richard Stallman, Bret Victor invite son auditoire à suivre leur exemple pour identifier des problèmes que nul n'avait encore appréhendé pour y apporter des réponses innovantes.
Une approche qu'on retrouve tout au long de l'histoire d'Apple : résoudre des problèmes qu'on ignorait avoir. Vous pouvez voir les autres travaux de Bret Victor sur son site. Son passage chez Apple ne semble malgré tout pas lui avoir fait forte impression : sur la page qu'il dédie à cette période de sa vie, il indique qu'il y a créé de nombreuses choses, mais celles auxquelles il tenait le plus n'ont jamais dépassé le stade de la démo. De manière facétieuse, il indique qu'il publie dans un cadre toutes les choses qu'il a le droit de partager en espérant que cela en inspirera d'autres, mais le cadre en question est désespérément vide, et suivi d'une FAQ :
Q - Mais ce cadre est vide !
A - Oui, exactement
Q - Ah, d'accord, je croyais que c'était une erreur
A - Oui, exactement.
Ceux-ci sont particulièrement intéressants, notamment pour quiconque a déjà développé dans sa vie. Pour Bret Victor, le développement se fait "à l'aveuglette" : on tape du code, on compile, on voit le résultat, et on recommence, au lieu de voir directement les modifications mises en application.
Cela présente deux inconvénients : d'une part nombre de bugs pourraient être évités, et d'autre part le simple fait de pouvoir constater directement les effets des modifications dans le code est en soi-même un excellent moyen d'avoir de nouvelles idées.
Dans cette conférence d'une heure, Bret Victor a donc présenté un outil qui permet de voir directement les effets concrets que peuvent avoir des modification d'un code en JavaScript. Il est ainsi possible de modifier chaque valeur numérique à la souris pour en voir les conséquences dans une fenêtre séparée. Sur un petit jeu, il peut ainsi modifier les paramètres pour les ajuster au pixel près. Mieux encore, son système permet de rejouer la partie qu'il vient de faire à n'importe quel point dans le temps, et même une représentation temporelle montrant toutes les positions du personnage : là encore, les trajectoires affichées sont modifiées rien qu'en ajustant les valeurs numériques de son code, de manière limpide.
Bret Victor souligne une autre incongruité du métier de développeur : en écrivant le code, il faut "jouer à l'ordinateur", c'est à dire imaginer les résultats de ce que l'on écrit, avant de pouvoir les constater de visu. Ceux qui sont les plus doués à ce jeu de l'esprit font partie des meilleurs développeurs, mais pourquoi "jouer à l'ordinateur" quand l'ordinateur lui-même pourrait jouer son propre rôle? Il fait la démonstration d'une fonctionnalité qui permet d'appliquer des valeurs d'exemple à une fonction alors même qu'elle est en cours d'écriture (en l'espèce une recherche par dichotomie), ce qui lui permet de se rendre compte directement des cas de figure qu'il n'a pas géré dans sa fonction et ainsi d'éviter plus facilement des bugs.
Et ce principe peut être décliné à l'infini : il présente par la suite le cas d'un schéma électronique… fonctionnel, c'est à dire simulé par l'ordinateur. Là encore, il fallait imaginer le résultat avant de pouvoir le vérifier dans les faits. Là aussi, il peut modifier les valeurs à la souris et constater directement leurs conséquences, ou surveiller le voltage entre chaque composant et les comparer d'un simple survol de la souris.
Il compare l'approche actuelle de la programmation à sa propre genèse : les cartes perforées. Celles-ci ne prenaient pas en compte le concept d'interactivité, et pour cause, puisqu'il fallait poinçonner ces cartes pour pouvoir entrer la moindre instruction dans un ordinateur, sans même avoir un retour vidéo. Il est donc plus que temps de reléguer cette approche au passé auquel elle appartient.
Enfin, il présente un outil d'animation sur iPad qui offre une approche beaucoup plus intuitive que les outils de Flash, puisqu'il permet de réaliser les animations "aux doigts", en temps réel. Là encore il suit sa philosophie de l'approche directe et du retour en temps réel sur une création dont les résultats sont d'ordinaire présentés en différés.
De ce principe simple, l'utilisation même de nombreux outils pourrait en être bouleversée, offrant une approche directe et intuitive, un énorme gain de temps, et la naissance de nouvelles idées alors même que l'on "joue" divers scénarios sur ces outils.
En s'appuyant sur l'illustre exemple de Larry Tesler, un ingénieur du Palo Alto Research Center de Xerox qui mit un terme aux différents modes de manipulation de texte, inventant au passage le couper-copier-coller (il travailla plus tard sur le Newton chez Apple), Bret Victor va plus loin encore en bâtissant une réflexion au niveau social : le grand mérite de Larry Tesler a été d'identifier et de résoudre un problème qu'il était le seul à voir. Pour tout le monde, les modes faisaient partie de l'informatique et nul n'imaginait qu'il puisse en être autrement, de la même manière qu'Elizabeth Cady Stanton a réalisé que les femmes devraient avoir le droit de vote. Faisant appel à d'autres illustres prédécesseurs tels que Doug Engelbart (lire Une vieille histoire de rongeur), Alan Kay, ou Richard Stallman, Bret Victor invite son auditoire à suivre leur exemple pour identifier des problèmes que nul n'avait encore appréhendé pour y apporter des réponses innovantes.
Une approche qu'on retrouve tout au long de l'histoire d'Apple : résoudre des problèmes qu'on ignorait avoir. Vous pouvez voir les autres travaux de Bret Victor sur son site. Son passage chez Apple ne semble malgré tout pas lui avoir fait forte impression : sur la page qu'il dédie à cette période de sa vie, il indique qu'il y a créé de nombreuses choses, mais celles auxquelles il tenait le plus n'ont jamais dépassé le stade de la démo. De manière facétieuse, il indique qu'il publie dans un cadre toutes les choses qu'il a le droit de partager en espérant que cela en inspirera d'autres, mais le cadre en question est désespérément vide, et suivi d'une FAQ :
Q - Mais ce cadre est vide !
A - Oui, exactement
Q - Ah, d'accord, je croyais que c'était une erreur
A - Oui, exactement.
Mouais c'est surtout encourager le developpement a la rash & quick fix.
Des spec bordel!
Et reflechir 2s, faire des algo avant de se jeter sur le clavier et pisser du code!
Après il n'y aura pas de surprise
@ShowMeHowToLive
Quartz Composer utilise un super système de briques à lier :
http://en.wikipedia.org/wiki/Quartz_Composer
http://upload.wikimedia.org/wikipedia/en/b/bc/QuartzComposerSnowLeopard.png
«encourager le developpement a la rash» ?
«à l'arrache», non ? À moins que de coder provoque un prurit ;-)
Moi je trouve cette idée geniale.
Tout les programmeurs, n'ont pas forcement de diplomes, ou n'ont pas forcement eu de formation.
Donc toute aide, peut etre utile.
Et a part critiquer H24 sur ce forum, certains ne font rien.
Tension et pas VOLTAGE.... Merci :-))
C'est un peu ce que je fais en programmant avec LiveCode.
http://www.runrev.com/
et cela depuis 1987 avec le défunt HyperCard d'une société dont je ne me souviens plus du nom...
Ah oui, cela me revient ... : Apple !
@Amonchakai
Arrête un peu 2s... Ce type propose aux développeurs la possibilité d'observer et modifier en direct le résultat de leur travail, comme un sculpteur ou un peintre, et tu trouves encore le moyen de te plaindre... Ce qu'il propose est révolutionnaire... Réac!
L'idée est très intéressante ; plutôt que d'imaginer comment un algorithme va fonctionner, pourquoi effectivement ne pas déléguer cette tâche à l'ordinateur. Mais la question est : cela aide-t-il vraiment à la créativité.
Quand je code et que je vois que je ne m'en sors pas, je prends un papier et un crayon et je repose le problème. Souvent en faisant ainsi d'autres idées bien meilleures émergent. Ou alors je vais aux toilettes. Ca marche aussi.
Ce type est simplement un GENIE! C'est tout! Inutile de jouer les devs plus puristes que CE puriste... Car c'est ce qu'il est.
Avec un outil pareil: plus d'excuse pour faire du "bancal-pourri-plombé"... ;D
Mais enfin cela existe depuis toujours avec les langages interprètes par un interpréteur meta-circulaire (CLOS par exemple).
@amigafred91 :
C'est bien là le problème, certains "programmeurs" sont en fait des pisseurs de code incompris et copié-collé en vrac avec pour seul but "que ça marche".
C'est une plaie dans notre profession et je suis pour une bonne formation (pas forcément des diplômes, mais bon)...
Croire qu'on pourra créer un logiciel sans savoir définir un langage mathématiquement, croire qu'on est développeur sans pouvoir apprendre un langage informatique inconnu en une semaine* c'est MAL.
Il y a même des "développeurs HTML/CSS" alors que ce n'est qu'un langage descriptif ...
Si je suis d'accord pour dire que la programmation peut évoluer, je maintiens que le développement logiciel est un METIER et qu'on ne laisserait pas un excellent bûcheron nous soigner une carie...
*Privilégier la compréhension du fonctionnement à la forme. Si on connait les principes de bases, on peut assimiler n'importe quel langage rapidement.
Non, mais quand tu reflechi avant et que tu ne code pas au hasard, tu n'as pas besoin de voir ce que fait le fait de changer la moindre ligne de code pour voir si cela ne tomberai pas en marche si tu changes les index de boucle, si je rajoute un test a tel ou tel endroit, est ce que tout tombes ou resouds le bug?
C'est le probleme de tout debutant qui code au hasard
L'implementation c'est sensé etre annexe, tu reflechis, des spec. tu fais des algo que tu eprouve. Tu es sencé maitriser ton outil, et il n'y aura pas de mystere a la sortie.
coder a la va vite et modifier le code a la volée pour corriger les bugs et autre. Ouais c'est revolutionnaire.
edit: @Un Vrai Type, oui voila!
Mais c'est ridicule ! Encore une fois, on prétend avoir réinventé la roue !
Ce type de programmation existe depuis longtemps, dans les langages qui tournent sur une machine virtuelle... Le java pour commencer sait faire cela depuis des années, et bientôt le .net saura le faire ! Arrêtez, NON, ca n'est pas une révolution !
@amonchakai
Tu réagis en vrai pro.... du siècle dernier... Le but de l'informatique au final n'est pas de réserver ces outils aux puristes super pro bac +56, mais de l'amener au plus près de tout le monde... Ce logiciel, comme ibook author, FCPX etc etc font hurler dans les chaumières... des pros vieux de la vieille... Ils ont l'impression qu'ont leur enlève le pain quotidien...
Mais même toi, super prog, avec tous tes algo aux piles poils en ordre avant même d'avoir écrit la moindre ligne de code tu n'es pas infaillible.... Et tu feras des erreurs, des oublis, qu'un outils comme celui-là te permettront de voir instantanément.... Sans devoir tout compil et se rendre compte de son erreur.... Donc si tu es un bon programmeur, utilise ce genre d'outil, il te fera gagner du temps, donc la possibilité de passer plus de temps surt d'autres fonctions, donc ton prog sera encore meilleur....
@Un vrai type
+1000
il faut comprendre ce qu'on fait !
sans parler de l'optimisation de code…
Mais, cette méthode, pour débugguer du js, je ne dis pas !
@debione on utilise déjà ce genre d'outil depuis environ 35 ans. Smalltalk est énormément utilisé pour le prototypage d'applications et particulièrement dans le système Squeak. Si les POC, plaisent que les algos sont valides alors on implémente dans un langage type C/C++ ou langage de plus haut niveau si ont à pas besoin de performances importantes.
Programmer est un art qui s'appuie sur des sciences!
Il faut faire la distinction entre le design global (les fonctionnalies et leurs interactions), la construction de l'interface et l'algorithmique.
Produire un logiciel aujourd'hui demande dans la majorité des cas d'avoir trois niveaux de profession qui travaillent:
-le concepteur qui définit le concept et ses fonctionnalites
-l'ergonome: qui cree l'interface et definit les interactions numeriques/analogiques
-le programmeur: qui code et assemble les diverses parties pour les faire fonctionner
En fonction du logiciel le role de chacun des intervenants sera plus ou moins long et significatif.
Knuth a définit l'art de programmer "litteraire" ou comment assembler des algorithmes et decrire ces systemes de maniere compréhensibles et previsible et relisible...
Wirth a développé le modele procedurale afin de rendre le code le plus proche de l'algorithme et d'en assurer le fonctionnalite et la securite.
B.Meyer en développant l'approche objet et la programmation par contrat a permis de rationaliser et standardiser la conception de composants logiciels dans une dimension industrielle et de permettre d'appliquer la securisation du code de maniere systemique...
JM Hulot a développé Interface builder rendant la conception d'interface plus rationnelle et modulaire...
Il y a eu meme des grandes avancées de conception de "briques logicielles", avec Smalltalk (annees 70 pourtant) et les travaux d'A.Kay.
Ou encore il y a eu toute une serie de soft de développement "visuels": on liait des briques logicielles entre elles et on definissait des relations tout autant visuellement... A part un ou deux softs d'ingénieries cela n'existe plus!
Il y a eu aussi Hypercard, un outil genial pour developer une idee, prototyper un concept... et donner a beaucoup de non programmeurs la possibilité de developer eux meme leurs idees, sans se poser la question de la rentabilité, bref l'imagination au pouvoir au quotidien. RIP by Apple!
Il y a bien d'autres qui ont travaille sur comment rendre plus fonctionnel, plus sur et plus durable l'écriture de logiciel, et parmi les gens les plus intelligents quis soient.
Or il faut constater une chose: malgré toute cette intelligence, aujourd'hui on écrit les logiciels en C (quelque chose pour faire moderne et sense corriger les failles du C originel... Mais qui reste du C:un des pires langage de programmation qui soit, difficile, illisible et producteur de bugs), a la main et on a l'habitude réinventer la roue tous les jours... comme dans les annees 70.
On code les sites Web (LE media de l'information et de la connaissance) avec du PHP, du HTML/CSS, du Javascript, trois langages primitifs, approximatifs et totalement différents dans leurs concepts, leurs approches et leurs realisations...Impossible d'avoir quelque chose d'unifie et coherent...
Les seules avancées sont les framework (sense compenser les failles du langage et du developpeur), imposées par les producteurs d'OS commerciaux, et un peu les IDE. On commence aussi a voir des demonstrateur de validité de code, mais c'est encore tres anecdotique..
Alors les idees y en a eu, y en a surtout de tres bonnes developpees au tout debut de l'informatique, mais voila on reste dans son bac a sable, a reinventer l'age de pierre tous les jours. Pourquoi?
Peut etre la réponse se trouve elle quelque part ici http://www.fsf.org/
Ça me rappelé les logiciels de création web, "what you see Is what get"
À lire certaines réactions, c'est à s'en demander pourquoi diable on a cru bon de faire des beta-tests, il suffit de n'embaucher que les vrais pros qui savent tout prévoir à l'avance sans la moindre faille…
@debione
"Le but de l'informatique au final n'est pas de réserver ces outils aux puristes super pro bac +56, mais de l'amener au plus près de tout le monde... "
De ce côté là le logiciel n'apporte pas grand chose : il permet de débugger et de tester rapidement mais n'écrit pas le code à la place du développeur !
Sinon effectivement c'est un vrai plus, pour le dev confirmé comme pour le débutant.
Encore un génie qu'Apple n'a pas su garder.
@jujuv71
Tension n'est pas forcément voltage.
Tension électrique, oui.
Par ailleurs, bien que souvent opposé aux anglicismes envahissants, "Voltage" me parait bien mieux décrire la fonction et me paraît plus naturel d'usage.
@sugarwater :
what you see is what YOU get.
@rom54
"Il y a eu aussi Hypercard, un outil genial pour developer une idee, prototyper un concept... et donner a beaucoup de non programmeurs la possibilité de developer eux meme leurs idees, sans se poser la question de la rentabilité, bref l'imagination au pouvoir au quotidien. RIP by Apple! "
Je veux pas dire mais des trucs proprios comme hypercard…bof ! Le wiki sur hypercard (pour 1 fois) est plutot bon. Pour ceux qui ne connaissent pas cette vieillerie.
Dashcode n'est pas si eloigné du concept pour des applis basiques (widgets)
@debione :
'Le but de l'informatique au final n'est pas de réserver ces outils aux puristes super pro bac +56, mais de l'amener au plus près de tout le monde... '
Non, ce n'est pas le but de l'informatique. Le but de l'informatique est de faire traiter une information par une machine. Pour cela il faut expliquer à la machine ce qu'elle doit faire et comment elle doit le faire.
Ce n'est pas à la portée de tout le monde tout simplement car cela nécessite des compétences, des connaissances et de l'expérience.
@domsou
Oui, on a aussi dit cela des softs de montage vidéo, de musique... Allez, je tente un pari: tu es programmeur, ou en tout cas tu programmes...
Et non actuellement ce n'est absolument pas à la portée de tout le monde, exactement comme un cubase n'est pas à la portée de tout le monde alors qu'un garageband si... Et pourtant la qualité de ce qui sortira n'est absolument pas dépendant du prog utilisé, mais bien de celui qui l'utilise... Le prob est que si on a que des cubase, ben on enlève au 99% de la population l'occasion de faire quelque chose en mao...
On a déjà un début de réponse avec certain prog qui permettent à des non initié de faire le petite page web perso, sans taper une seule ligne de code... Cela fait hurler les prog, c'est de la merde, seul un prog qualifié avec moult diplôme est capable de faire une page internet...
Il serait franchement bien que l'on arrive à des outils que tout un chacun puissent utiliser sans avoir fait 10 ans d'études... Et t'inquiètes pour ton job, il faudra toujours des prog de haut niveau pour développer ce genre d'outils...
La musique n'est plus réservée aux musiciens, la photo aux photographes, le montage vidéo aux boites de prod etc etc... Voila ce que l'informatique à amené.... Reste plus qu'a offrir la possibilité de programmer à des non programmeur...
Mais les musiciens/photographes/monteurs qui se disent pro font des ouins ouins on nous enlève notre job... Maintenant c'est le tour des programmeurs...
Et il y a ceux qui ne disent rien, parce qu'en tant que vrai pro (et non pas titre qui en jette grave (dixit super munchkin) ils s'en foutent royalement que mrs tout le monde aie accès à des outils lui facilitant la vie...
L'homme au service de l'informatique est un vieux paradigme, ce serait bien que dans ce siècle ce soit l'informatique qui se mette au service de l'homme.
[quote=BKN1 [16/02/2012 14:19]
Je veux pas dire mais des trucs proprios comme hypercard…bof ! Le wiki sur hypercard (pour 1 fois) est plutot bon. Pour ceux qui ne connaissent pas cette vieillerie.
Dashcode n'est pas si eloigné du concept pour des applis basiques (widgets)
[/quote]
Le mode de distribution est un sujet different du concept que represente le logiciel. Ce qui a tue Hypercard c'est justement et uniquement le fait qu'il soit reste proprietaire et developpe par la funeste Claris...
Sinon Hypercard etait un concept et une evolution majeurs ayant fortement inspire le développement du Web. Son langage etait simple et assez intuitif, tres loin des bizarreries de Javascript.
Hypercard a ete un des plus gros succes et un de premier du concept d'hypertext, c'etait un media extraordinaire pour developper des bases de savoirs.
Mais Apple n'a jamais rien fait de coherent pour pousser le concept et en faire une specificite du Mac ( ce qu'etait tout de meme Hypercard pendant quelques annees).Apres il y a eu les clones d'Hypercard qui se sont multiplies, mais soient a des prix exhorbitants -la force d'Hypercard c'etait d'etre accessible a tout le monde- ou terriblement instables, mal optimises et tres lourd.
Aujourd'hui ibooks author se rapproche un peu des possibilites d'hypercard, mais reste encore tres loin de certaines fonctions extremement poussees comme la navigation non lineaire.
En abandonnant Hypercard Apple a tourne le dos a un de ses fondement et un principe meme de Jobs: offrir a chacun l'outil pour realiser ses idees...
Hypercard fait partie de ces vielleries comme Lisp ou Smaltalk qui sont toujours plus avancees que leurs successeurs et descendants...
Quant a Dashcode, moais c'est un outils assez limite pour creer des widgets simples, rien de bien transcendant et il existe beaucoup mieux et depuis longtemps sur Linux...
@oby1
C'est pas moi c'est mon iPad qui a mangé le mot:D
On va faire court : Progiciel
Un logiciel pour un problème !
Un langage ou une interface ? Qu'importe ! Problème équivalent !!!
Il est certain que pour faire de l'animation il faut travailler avec une base de temps. Donc le C : exit ! ?
CQFD
@debione :
Vous évoquez le sujet des études alors qu'il ne s'agit absolument pas du propos de ce sujet, ni de mon commentaire.
Libre à vous de croire ce que bon vous semble concernant la science informatique et notamment qu'une certaine caste souhaite préserver sa chasse gardée : diminuer la valeur et le mérite d'autrui donne l'impression d'augmenter sa propre valeur.
Libre à vous de croire qu'il suffit à n'importe qui de prendre l'outil adéquat pour obtenir au final le même travail que celui d'une personne dont c'est la spécialité et qui a les compétences.
Connaissez-vous au moins le domaine du développement informatique ? Ou bien êtes-vous un développeur auto-formé qui déverse sa frustration ?
@Domsou
Je n'enlève aucun mérite à qui que ce soit...
Ce que je dis: C'est que les bonnes idées ne sont pas l'apanage des spécialistes...
Un spécialiste avec des compétences ne fera pas forcément un bon programme.... On peut demander à un spécialistes de faire un super coussin péteur, ça restera du caca, même si c'est codé à merveille...
De même un musicien peut avoir toute la technique qu'il veut, il ne sera pas forcément capable d'improviser (j'ai quelques exemple de pianiste virtuose dans mon entourage), de faire autre chose que ce qu'il connait déjà...
Je pourrais très bien faire un très bon morceau de musique sans avoir touché un seul instrument de ma vie, grâce aux logiciel actuel (il faut de l'idée et de l'oreille, pas besoin de connaître toutes les gammes chromatique), pourquoi en serait-il autrement avec la programmation?
Permettre aux gens qui ont les idées mais pas la technique de pouvoir les mettre en place facilement, cela vous semble immoral? Alors certes, on peut réunir les deux, mais ces personnes la sont très très rares...
Il y a le savoir technique, mais le savoir technique n'a jamais fait qu'un prog soit bon ou pas... Je préfère largement un prog avec quelques bugs dedans mais qui sera intuitif et utile qu'un prog codé pile poil mais dont je me fout éperduement...
@debione :
Vos propos démontrent que vous ne connaissez pas le domaine : comparer un développement technique à un développement artistique pour argumenter est erroné. Je pourrai répondre par exemple que n'importe qui peut avoir des idées d'architecture géniale mais sans savoir faire technique ne peut les réaliser tout seul.
@Domsou
Il me semble que c'est vous qui ne voyez pas ou je veux en venir: Allez demander à un danseur si la technique n'est pas la base? Faites la même chose avec un guitariste, un pianiste, un étalonneur, un monteur... N'importe quel domaine artistique réclame de la technique, énormément de technique, qui plus est dans le domaine artistique la technique se perd si elle n'est pas entrainée... L'aspect artistique c'est complètement autre chose... Igwie Malmsteen est un des guitariste les plus incroyable techniquement qu'il m'est été donné de voir, vraiment hyper impressionnant, par contre artistiquement à mon goût mon gamin de 5 ans est plus doué...
L'ordinateur permet justement de faire "sauter" certaines contraintes technique, c'est même la base même de l'ordinateur... Il a été mis en place pour que les contraintes techniques soient moins grandes (Imaginons devoir faire à la main une prédiction météo) pour les humains... Cela c'est senti dans le domaine grand public en premier lieu avec la photo numérique... Les pros (certains) ont hurler au lynchage, que s'en était fini du métier... Hors actuellement, excepté quelques rares occasions, tous les photographes utilisent le numérique (ce qui n'empêche pas que le "bon" pro fera des clichés toujours plus intéressant que le bon amateur, mais maintenant le bon amateur peut lui aussi avoir accès à la création photographique sans devoir utiliser une pièce de son appart pour faire une chambre noire)... Même chose pour la musique, la vidéo, cela arrive gentiment dans le développement d'animation et la création web... Alors quoi, la programmation qui est par essence même une contrainte technique ne pourrais pas suivre le même chemin?
c'est ce qui est entre l'ordinateur et la chaise qui fait que l'objet sorti est chouette ou non.
C'est comme les "virus" qui infectent.
Si vous avez une bonne base technique, vous vous en sortirez mieux mais les idées n'arrivent qu'à ceux qui cogitent, la technique est excellente aide.
(suite)
Pour reprendre votre exemple d'architecture, car ceci est un très bon exemple de ce que je veux illustrer... En effet actuellement, on peut avoir les idées les plus géniales mais qui sans le savoir technique ne seront pas réalisable... La cause? Actuellement aucun programme d'architecture n'est capable de se substituer aux techniciens... Mais pour combien de temps? Juste le temps qu'il faudra pour concevoir un programme qui sera lui-même le technicien, et qui vous empêchera de faire des choses techniquement impossible.... Et ce jour la nous verront apparaître une floppée de techniciens pour hurler que rien ne remplace un technicien... Sauf un soft bien pensé et développé...
@debione :
Je comprends parfaitement vos propos. Néanmoins nous parlons de science et ce qui est valable pour le domaine artistique n'est pas valable pour la science. Une belle musique est affaire de subjectivité. Un programme qui fonctionne correctement non. Il y a l'épreuve de la réalité : froide et impartiale.
@debione :
ah ah ah ! Doux rêve des années soixante ! Peut être que cela arrivera un jour. Mais pour le moment c'est l'homme qui dit à la machine quoi faire et comment le faire. On peut faire effectivement énormément de choses avec des outils logiciels. Mais cela ne remplace pas l'homme.
Mais pour le coup on s'est complètement éloigné du sujet.
@Domsou :
c'est le syndrome "yaka" : tout est simple avec des mots. Yaka, fojuste... En attendant, prenez votre clavier et essayer de concevoir un logiciel, si petit qu'il soit. Et après on en reparlera si vous voulez bien.
Loin de moi l'idée de dire que la prog c'est easy... j'ai quasiment jamais touché (excepté quelques legne de basic avec mon vic20 il y a 30 ans...)...
Mais il se serait passé la même chose avec la vidéo si on n'avait pas fait sauter les contrainte technique grace aux progrès informatique, hors ce qui était techniquement impossible pour moi lors de mes début dans l'informatique (à savoir le montage vidéo), maintenant j'y ai accès, justement parce que les contraintes techniques ont quasiment toutes disparue... Cela ne fera de moi pas un bon cameraman/monteur pour autant, cela est sur, et même un monteur qui sera passé par une école sera sans doute bien plus doué que moi (en fait non, il saura simplement bien avant moi que le chemin emprunté est un cul de sac ou donnera de la merde)...
Après justement ce qu'il est dommage actuellement, c'est que je n'ai aucun moyen de concevoir un programme aussi petit soit-il... Mais il en était de même au début de l'internet, impossible pour moi de concevoir la moindre page web... Je n'ai actuellement pas plus de connaissance en css/html qu'il y a 15 ans, mais contrairement à il y a 15 ans, maintenant grâce aux développement des outils, je peux concevoir un site sans taper une seule ligne de code (simple cela va de soi)... Donc je répète ma question, pourquoi est-ce que la programmation d'un programme serait différente de la création d'un site web? Pourquoi ce qui a été développé comme outils pour le net n'aurait pas leurs pendant dans l'avenir dans la programmation?
Vous confondez il me semble un peu l'idée et sa réalisation.... Ce n'est pas parce que la réalisation demande moins d'effort technique, que cela en fait quelque chose de moins attractif, de moins bien fini de plus ou moins utile...
Je me suis toujours demandé pourquoi il y avait si peu d'évolution dans certain domaine de la création, l'exemple des architectes et des techniciens illustre bien ce problème.
Un architecte ou un technicien ne va pas créer un outil qui va permettre de se passer de son expertise.
Un programmeur ne va pas créer un programme qui permet de se passer de programmeur.
Il va créer un outils facilitant la vie des programmeurs, des architectes, ne permettant pas de s'en passer.
C'est l'instinct de survie qui dicte ce comportement.
C'est logique.
Personne n'a envie de créer une chose capable de détruire son secteur d'activité, son gagne pain, son moyen de subsistance!
Les connaissances nécessaires au développement de tel outils représentent bien trop d'heure d'étude, ou d'investissement pour avoir envie de sacrifier tout cet apprentissage ou cet argent, dans les mains d'un concurrent...
Évidement, il existe des programmes permettant de faire de la programmation sans programmer, de faire de l'architecture sans connaitre la technique, mais ces programmes restent au niveau de jouet, et ne sont évidement pas destiné à un usage professionnel, ou concret.
Le reste restera des outils internes à une entreprise, et ne seront jamais public.
"Une belle musique est affaire de subjectivité."
- C'est complètement faux, une belle musique répond toujours à des règles mathématiques.
Ensuite tous les goûts sont dans la nature, mais une mélodie ou un truc de musique potable répond à des règles mathématiques.
@redchou :
Oui vous avez raison. Il y a un complot international de la caste des développeurs pour garder la main mise sur la création des logiciels.
On aura tout lu...
Il y a un outil de développement développé depuis le milieu des années 80 d'abord à l'IRCAM puis par Cycling 74 et qui a un fonctionnement sur ce principe : C'est Max/MSP (et PureData une version libre réalisée par le développeur initial de Max/MSP).
On appel les programmes développés avec Max des "patch". Ces patch sont constitués de briques reliées par des connexions, un peu comme des schémas électroniques. Mais ce qui est "super cool", c'est qu'on peut modifier ces patchs pendant qu'ils tournent, en direct et pas en simulation. Max/MSP est souvent utilisé pour produire des applications liées à des capteurs physiques dont ils traitent les données en temps réel, et inversement avec un patch Max/MSP, on peut générer en direct du son, de la vidéo ou piloter des "acteurs" physiques, connectés à l'ordi. Ainsi, on peut modifier ses patchs en direct alors qu'on est en interaction avec eux via les interfaces physiques...
http://en.wikipedia.org/wiki/Max_(software)
http://cycling74.com/
Pour ceux qui veulent programmer sans écrire une seule ligne de code, il y a labView de chez National Instruments ( http://www.ni.com/labview/f/ ).
J'avais trouvé ça assez bluffant. Dommage que personne ne reprend l'idée du langage G pour faire autre chose que de l'embarqué ou du dev de contrôleurs.
Avec le Lego Mindstorm NX 2.0 il y a une version dégradée de labView.
@jujuv71: Tension et pas VOLTAGE.... Merci :-))
Si tu connaissais la loi d'Ohm, (U=RI) tu saurais que le Volt est l'unité de tension et que, par conséquent, ta remarque est inopportune . (on peut dire pour I : intensité ou ampérage)