Pas de soucis je suis patient (et surtout curieux car j'avoue ne pas avoir de bons aprioris sur motif, mais peut-être ai-je tort)
Pas de soucis je suis patient (et surtout curieux car j'avoue ne pas avoir de bons aprioris sur motif, mais peut-être ai-je tort)
<troll velu="true">
C'est vrai pourquoi être passé à l'automobile? Le cheval ça allait très bien!
(Non je plaisante, tapez pas. )
</troll>
Je pense que les possibilités d'aujourd'hui sont quand même plus grandes, mais sans le savoir-faire qui va avec c'est inutile. C'est comme ça que je choisis d'interpréter ce post.
A toutes les époques il a du y avoir des gens capables de faire du bon boulot, d'autres pas, peu importe les moyens à disposition.
ouaip enfin si je compare une interface GWT et une ancienne d'une bonne appli d'il y a 10 ans... Alors peut être que certaines choses étaient possibles il y a 10 ans mais il fallait quand même être une bonne brutasse
(mais je digresse puisque la je ne parlais pas de java ou de C++)
C'est tout simplement que les API comme Motif peuvent en faire autant, mais que Qt, wx & autres mâchent bien plus le travail, et propose de tout gérer directement à un niveau supérieur d'abstraction.
C'est effectivement le principe
Les possibilités d'Unix n'ont pas changé mais elles sont plus faciles à mettre en oeuvre.
Par exemple, en plus de la GUI, Qt inclus un parseur XML, le moteur de rendu HTML WebKit, l'accès au réseau, aux threads, aux bases de données, à OpenGL, à Phonon (pour le son et la vidéo), à DBus (pour la communication inter-processus), un moteur de script, un moteur de rendu SVG, de très bonnes possibilités d'internationalisation avec possibilité de faire des choses comme
(en Anglais, le 's' sera placé si nbFiles=0 ou si nbFiles>=2 ; en Français, seulement si nbFiles>=2 car les conventions ne sont pas les mêmes) et des outils comme Qt Assistant (pour l'accès à la documentation, qui est très bien faite), Qt Designer (pour la conception d'interfaces graphiques) et Qt Linguistic (pour la localisation).
Code : Sélectionner tout - Visualiser dans une fenêtre à part tr("%n file(s)","",nbFiles)
Ajoutez à cela une très bonne intégration au bureau (look & feel natif sous Windows et Mac OS X ; sous Linux, possibilité d'utiliser un style GTK+ et, sous Mac OS X, placement automatique des éléments de menu "Quitter", "Préférences" et "À propos" dans le menu qui porte le nom de l'application plutôt que dans "Fichier", "Aide" ou autre).
Pfiou, j'ai fini
Alp a raison, et c'est surtout qu'il n'y a jamais eu d'Atelier Logiciel Motif.. (enfin il y en a eu 2, mais ils n'étaient pas brillants).
Avec Delphi, Vb, VC++, c'est juste du drag&drop, avec accès à quelques propriétés..
Avec Motif, c'est de la construction manuelle, avec accès à toutes les propriétés..
Alors les autres outils sont plus faciles pour les débutants, et ça donne bonne conscience à beaucoup, car ils n'ont pas à comprendre le détail des widgets et des actions..
Mais c'est comme un graphiste (un vrai, dans la pub) : par rapport au clampin moyen qui fait de la présentation pour son patron, un graphiste , un vrai, doit connaître toutes subtilités de l'imprimerie industrielle (pour savoir si telle couleur sera reproduite exactement) de son soft (que ce soit QuarkXPress ou autre soft spécialisé), etc etc..
Il y a les "pros" et les autres
C'est la raison pour laquelle beaucoup d'IHM Motifs sont moches : c'est parce que les programmeurs ont juste utilisés les valeurs par défaut, qui sont la base pouvant passer sur un écran minimal , et non pas la palette des propriétés, en faisant du vrai design.
Les L4G ont eu des équipes de gens plus ou moins compétents ergonomiquemt pour "préparer" les défauts des widgets (et quand on va ceux de Wx par exemple, ils étaient pas plus brillants que ceux de Motif)...
ok bon ben j'attends le pro qui sait faire ca en motif :
http://www.studyblue.com/sb/Blue.html
(j'aurais pu mettre Gmail ou Wave aussi)
Ca devrait pas être bien bien dur, ca a été fait avec une api simple qui ne propose pas l'accès à toutes les propriétés. En plus c'est de l'html et du javascript, franchement les technos pour "hard core programmer qui savent modifier leur kernel linux" devraient aisément le faire.
Non ?
(ca doit évidemment être possible mais après j'aimerais qu'on compte le nombre de lignes de code et qu'on évalue la maintenance derrière )
encore une fois ce genre d'argument sous-entend que les développeurs utilisant des API "vieillotes et bas niveau" ne savent pas réutiliser leur code, et créer leur propre "sur-ensemble" avec tout plein de widgets aussi haut niveau et parfaitement adaptés à leur façon de travailler
from scratch il est évident qu'il y aura plus à maintenir, mais en réalité, qui te dit qu'il n'y aura pas "juste" 2 fois plus de code, car 20 ans à améliorer sa bibliothèque, ça doit quand même finir par donner quelque chose de potable et productif... ou alors faut changer de voie
ah mais je ne dis pas le contraire, d'ailleurs a force de, je cite :
"réutiliser leur code, et créer leur propre "sur-ensemble" avec tout plein de widgets aussi haut niveau et parfaitement adaptés à leur façon de travailler"
ces fameux bons développeurs ont créé de nouveaux langages adapté à une finalité particulière. (dans l'exemple ci dessus, faire une IHM)
Comme quoi on est bien d'accord, on a fait du chemin en 20 ans et ce qui se fait maintenant profite des "pros" qui nous ont précédé.
Mais repartir de zéro aujourd'hui je ne suis pas convaincu que ce soit efficace
[mode ironie on]
Un jour je parlerais de ma fantastique expérience dans ma boite actuelle qui utilise un language vieux de 30 ans dont nous sommes les seuls a rester utilisateur dans le monde entier...
true story
[mode ironie off]
small talk ça voud dis quelque chose ???[mode ironie on]
Un jour je parlerais de ma fantastique expérience dans ma boite actuelle qui utilise un language vieux de 30 ans dont nous sommes les seuls a rester utilisateur dans le monde entier...
true story
[mode ironie off]
et ben on l'utilise
personnellement je ne me lancerais pas dans le remplacment de 20 de dev informatique d'une boite dans un techno particulière pour la remplacer en .NEt ou java, c'est le gouffre financier assuré. et en plus cela risque de ne pas répondre aux besoin métiers.
Oui mais parfois ces vieilles technos sont juste maintenues mais n'évoluent plus, c'est sûr qu'on ne jette pas une application qui fonctionne parfaitement à la poubelle pour perdre 2 ans homme à la réécrire, en revanche on peut se retrouver bloquer si :
- Plus personne n'est en mesure d'assurer la maintenance de la vieille application.
- Les évolutions de l'application sont bloqués par le manque de possibilités et d'API disponibles.
Je pense que parfois, ne pas investir dans les nouvelles technos c'est prendre certains risques.
C'est vrai que les mainframes ont arêtes d'évoluer et que fortran est tombé aux oubliettes....
et on ne rempalce pas 20 de dev par par des equipes de 1 a 20 personnes et 2 années hommes.
Si la techno est sensible pour ton entreprise tu aura fait en sorte de maintenir les compétences sur le long terme en formant des gens dessus.
Smalltalk est un langage qui a été un modèle pour bien des aspects de tous les langages mainstreams d'aujourd'hui. Le C++ lui doit beaucoup, par exemple.
Java par conséquent, +- directement.
Oui, tu as raison, Java ne s'est clairement jamais inspiré de C++
Java est né une quinzaine d'années après le C++. C++ s'est effectivement inspiré de Smalltalk parce qu'à la naissance de C++, c'était un langage plutôt apprécié et connu. Alors que Java et Smalltalk ont vraiment beaucoup d'années d'écart.
EDIT : et bizarrement on retrouve en Java la terminologie C++, pas la terminologie Smalltalk.
Euh les fanboys du C++ faut se calmer là. Je pensais pas trouver ici un débat aussi profond que "java a la même syntaxe que le C++ donc il a tout pompé sur le C++".
Il y a un certains nombre de mécanismes en java qui n'existent pas de près ou de loin en C++ et qui viennent de Smalltalk.
Enfin bref ce débat est toujours aussi stérile.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager