D'où l'inénarrable compile once, debug everywhere.Envoyé par Herve-Loiret
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
D'où l'inénarrable compile once, debug everywhere.
Je ne vois pas comment ils peuvent prétendre a la réalisation d'une interface massive, jolie et efficace lorsqu'il faut tout calibré au pixel de prés en plus du noyau du programme tout en respectant les dead lines imposé par de VRAI Clients. Parce que oui, MS n'as pas de client a qui répondre puisqu'ils s'attaquent au grand publique, contrairement a la majorité des autres développeurs.
et puis concrètement , ce que nous apporte les éditeurs dit : graphique
c'est la réalisation des interfaces pour nos programmes, coloration syntaxique et organisation des fichiers et des ressources + Le Débogages plus intuitif qui est indispensable dans de grand projet peu importe ce que ces gens peuvent dirent.
Pour le reste, c'est bien le développeur qui écrit le code. S'il y'a quelque chose de regrettable, ce ne sont certainement pas les IDE , mais les langages High lvl ou tout se fait a travers des classes abstraites a leurs utilisateurs.
et en y pensant, je dois me mettre au C!
alors là je ne suis pas du tout d'accord....
C'est rigolo, mais vous protestez quand des députés qui n'y connaissent rien, selon vous, votent Hadopi, mais vous trouver magnifique une philosophie qui est exactement ça...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Les député n'utilisent pas un outil efficace
Et puis, avec des argument comme ça, autant programmer en assembleur, parce que sinon, faut faire confiance à des outils comme le compilateur, sait-on jamais . . .
Non, mais un développeur qui connait rien en assembleur peut avoir des serieux ennui
Développes s'il te plaît, je suis très intéressé par l'explication ...
C'est très lié à ton domaine d'application. Dans 99% des cas, des connaissance en algorithmique seront bien plus profitables que des connaissance en asm.
Attention, ces connaissance ne sont pas exclusive, mais la connaissance de l'assembleur n'est plus primordiale pour bien des domaines. D'ailleurs, les expérience montrent que si le code était plus rapide en asm il y a quelques années, ce n'est plus le cas de nos jours, car les compilos sont capable de faire mieux que les humains (ormis quelques cas particuliers).
Il faudra toujours quelques spécialiste qui connaissent l'asm, et vers qui on se tournera quand on a une question spécifique. D'ailleurs, je connais l'asm sur x86 et ARM, et bien dans la pratique, je ne m'en sert pratiquement jamais de cette connaissance.
Ex : comprendre la différence entre un struct et une classe en c# si tu connais rien a l'utilisation de la mémoire et a la différence des passage de paramètre par valeur ou par référence, et ben tu peut avoir des question du style
"Je comprend pas dans ma fonction je passe un objet en paramètre mais je vois pas les membres mis a jour en sortie"
"C'est un objet ou une valeur"
"Euh je sais pas j'ai toujours fait avec struct"
Bien sur cela n'a pas a voir directement avec un langage assembleur en particulier ni une syntaxe, mais avec des principe qui sont plus bas niveau que la techno utilisée.
Ben non, on proteste quand ils ont manifestement pas consulté les experts! encapsulation ne veut pas dire opacité!alors là je ne suis pas du tout d'accord....
C'est rigolo, mais vous protestez quand des députés qui n'y connaissent rien, selon vous, votent Hadopi, mais vous trouver magnifique une philosophie qui est exactement ça...
Personnellement je suis à moitié d'accord avec le sujet d'origine:
- oui, il faut toujours savoir ce que fait l'IDE parce que l'IDE peut aussi se planter, ou mal interpréter ce qu'on lui dit de faire (je pense notamment à Eclipse qui décide régulièrement de perdre les projets j'ai pas encore compris pourquoi).
- Mais oui, des outils qui génèrent le code ou le rendent plus sympa (comprendre: avec des couleurs et des zolis dessins), ça peut changer la vie.
Je pense que les deux misters interrogés sont des développeurs de pointe, qui font du travail de pointe. Perso je bosse en informatique de gestion, et franchement les problématiques qui réveillent un peu les neurones, ben faut se lever tôt pour en trouver.
Et là sans IDE, autant aller chercher un tabouret et une corde...
Veuillez agréer nos sentiments les plus distingués. Soyez assurés de notre entière collaboration, bien à vous pour toujours et à jamais dans l'unique but de servir l'espérance de votre satisfaction, dis bonjour à ton père et à ta mère, bonne pétanque, mets ton écharpe fais froid dehors.
Un bon développeur doit connaitre ses outils et leurs limites.
Le refactoring sur une petite structure on un nom de données membres, ça passe. Il sait qu'il peut l'utiliser sans risque. dans le cas plus complexe que tu cite, il ne l'utilisera pas. La connaissance des outils que tu utilise est aussi importante que la connaissance du langage lui meme.
On ne peut pas dire qu'un RAD /IDE soit bon ou mauvais, il a de bonnes et de mauvaises fonctionnalités, suffit de les connaitre et savoir l'utiliser au mieux.
Par exemple, je fais du builder C++ depuis plus de 11 ans, ben je sais qu'il est hors de question d'utiliser le refactoring, meme le plus petit, ça peut (ça a déja!) finir en catastrophe. ça n'empêche que c'est un IDE bien pratique pour plein de raisons, mais je connais ses limites et je sais ce qu'il peut m'apporter et ne pas m'apporter.
Oui et non. Faut bien mettre la limite quelque part.
Par exemple, après l'assembleur, tu as la façon dont le processeurs interprète les instruction, fait les accès mémoire, puis ensuite, des connaissance sur la logique et la synthèse de circuit, puis sur l'éléctromagnétisme, etc . . .
Bref, faut bien s'arrêter à un endroit.
Et perso, bien que connaissant l'assembleur, je ne m'en sers pratiquement jamais dans la pratique. Je ne penses donc pas que cela soit forcement nécessaire. Au pire, avoir une ou deux personne dans une équipe connaissant cela est suffisant, à part projet spécifique (embarqué par exemple).
C'est la deuxième fois que tu sort cette phrase dans deux sujets différents
C'est un beau effet de style mais ça s'arrête là.
Si tu connais justement ce que te garantie ou non la JVM et que tu codes proprement tu n'a pas de problème.
A moins que t'es des exemples ?
Je ne pense pas qu'on soit tant que ça en désaccordalors là je ne suis pas du tout d'accord....
C'est rigolo, mais vous protestez quand des députés qui n'y connaissent rien, selon vous, votent Hadopi, mais vous trouver magnifique une philosophie qui est exactement ça...
Je suis contre un monde ou seulement les experts décideraient dans leur domaine, ça ne serait pas équitable...
Les députés sont capable justement de demander aux experts et ils font ensuite leur boulot qui est de légiférer.
Je dis pas qu'il faut utiliser bêtement des outils, je dis juste qu'il faut connaître comment se servir de l'outils, ses dangers, quelques caractéristiques et ça suffit.
On le fait tous avec notre voiture, notre ordinateur, notre téléphone, bref on peut pas tout connaître sur tout et il faut accepter d'utiliser certaines sans les décortiquer. En clair tu profite du travail des autres.
Si on remet tout en cause, où qu'on cherche à tout vérifier pour comprendre, on avancerais drôlement moins vite, il faut un minimum de confiance (j'ai pas vérifié que la terre était ronde ou qu'un humain était bien allé sur la lune par exemple).
Exactement
Yoshi
PS : tous les propos tenus dans le message ci-dessus sont à préfixer avec "A mon humble avis", "Je pense que". Il serait inutilement fastidieux de le rappeler à chaque phrase.
Je fais aussi du builder, et le RAD à la Borland me parait un excellent exemple pour cette discussion.
Builder est un formidable outil pour la construction d'interfaces utilisateurs. Son IDE permet de définir une interface, ses composants et toute la mécanique qui se trouve derrière, de façon très rapide, intuitive, et facile à modifier. Le framework qui va avec l'IDE (la VCL) repose également sur cette idée graphique, à tel point que quand on veut générer des composants non visuels (une requête SQL, par exemple) on les "pose sur une forme" comme un bête bouton.
Ces fonctionnalités de l'IDE orientent le développement que l'on fait à partir de Borland. Très naturellement les applis Builder ou Delphi ont tendance à devenir des "IHM intelligentes" dans lequel une grande partie du code métier est porté par l'interface et les fenêtres. Par exemple, si tu as une Form qui présente un tableau, la tentation de mettre tout le code métier qui va avec dans le module correspondant est grande (d'autant plus que Borland fournit des implémentations correctes de la plupart des structures non visuelles nécessaires, des chaines aux listes...
Pour un développeur qui ne ferait que du Borland (par exemple tous les dev Delphi), les "bons côtés" de leur IDE se traduisent par une certaine manière de programmer.
Inversement, on a connu des environnements dans lesquelles la programmation de l'interface était quelque chose de très abstrait et complexe. Dans ces systèmes, on avait tendance à plutôt ^mettre un maximum de code dans un "moteur" sans interface, conçu pour faire tout ce dont on pouvait possiblement avoir besoin, et appelé par une interface minimaliste, développée par des personnes dédiés.
Là encore, la structure du framework se traduisait par une organisation différente du programme.
Aucune de ces deux organisation n'est "la bonne", voire les deux ont des défauts, que les qualités des outils qu'on utilise font ressortir.
Je pense que c'est ce que veulent dire les deux "programmeurs star" de l'article. Je doute qu'ils soient contre le progrès, ou masochistes, ou séniles. Mais ils sont conscients du fait que les outils évolués ont tendance à "pervertir" la façon dont on code, en détournant l'utilisateur des principes de base.
Francois
Dernière modification par Invité ; 30/11/2009 à 21h30.
Oui, suffit de changer de JVM.C'est la deuxième fois que tu sort cette phrase dans deux sujets différents
C'est un beau effet de style mais ça s'arrête là.
Si tu connais justement ce que te garantie ou non la JVM et que tu codes proprement tu n'a pas de problème.
A moins que t'es des exemples ?
PS: « Java, compile once, debug everywhere » n'est pas de moi. C'est une maxime très connue.
Je parle d'exemple de code qui ne marche pas d'une JVM à l'autre...
Yoshi
PS : tous les propos tenus dans le message ci-dessus sont à préfixer avec "A mon humble avis", "Je pense que". Il serait inutilement fastidieux de le rappeler à chaque phrase.
C'est le cas par exemple de presque toutes les JVM mobiles. Il y a un topic la dessus dans le sujet java dans le monde du jeu vidéo. Tu y trouveras ce genre d'infos.
Tu me cites des KVM là, alors qu'en premier temps tu disais qu'il y avait des bug entre JVM
Yoshi
PS : tous les propos tenus dans le message ci-dessus sont à préfixer avec "A mon humble avis", "Je pense que". Il serait inutilement fastidieux de le rappeler à chaque phrase.
Ne serait-ce qu'avoir à faire ce différencement est un problème. Java est supposé être indépendant du système sur lequel il tourne alors qu'en fait il ne l'est pas du tout. On à les inconvénients sans les avantages.
Qu'est ce qu'on en a à faire de sur quoi ça tourne ? Ça ne devait pas être ça la grande promesse de java ? Faire tourner son code partout ? C'est pas pour ça qu'interagir avec le système directement à longtemps été impossible ? Vœux pieux d'ailleurs totalement en contradiction avec la politique de sun au début de java qui était totalement fermé (ce qui donne un message du genre faites tourner votre code sur toutes les platesformes ! liste de toutes les plates formes par sun :
- x86
- x86_64
- SPARC
- PowerPC)
Non pas du tout, il y a un système de profil et de configuration qu'il faut respecter.
Comment veux-tu que tu code qui envoi un sms sous le profil MIDP fonctionne sur une JVM d'un ordinateur ?
Comment veux tu qu'un programme qui utilise swing marche sur un téléphone mobile, quand on connait les contraintes de mémoire et de processeur qu'on a sur un téléphone (16/32 bits et 128ko de mémoire) ?
Pour faire une vague liaison avec le sujet, c'est là qu'il faut que le développeur en connaisse un peut sur la technologie qu'il utilise. Si il utilise Java sans connaître les profils et configuration, et qu'il essaye de faire tourner son programme PC sur mobile, c'est sûr qu'il sera déçu.
Tu voudrais que Java choisisse le plus petit dénominateur commun de toutes les plateformes sur lequel il tourne ?
Mais Java tourne sur des portables, des imprimantes, des lecteurs DVD, des voitures et j'en passe...
Non mais faut être sérieux, évidement qu'il y a des profils et des configurations, (MIDP et CLDC pour les mobiles) pour prendre en compte les contraintes et les opportunités des matériels sur lequel tourne ton programme.
Les programmes sont seulement compatibles entre JVM avec compatibilité ascendante.
Source ?
Yoshi
PS : tous les propos tenus dans le message ci-dessus sont à préfixer avec "A mon humble avis", "Je pense que". Il serait inutilement fastidieux de le rappeler à chaque phrase.
Bien sur, mais pourquoi alors empêcher l'interaction avec le système ? D'ailleurs JNI a fait son apparition depuis, et ce n'est pas pour rien.
Site de sun.Source ?
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.
Répondre avec citation
Partager