Alors si, je le dis, je trouve Mono/.NET ouachement mieux que Java, de mon point de vue.
...
Je trouve le socle technique ouachement mieux :
Je trouve le langage C# ouachement mieux que le langage Java : event, property, linq, lambda, inférence de type, etc.
...
Après tu trouveras sûrement tout ça ailleur, mais pas ensemble : et moi c'est tout ca sur la même plateforme qui la rend sexy. Et c'est pour la même raison que beaucoup de développeurs utilisent Mono.
m'enfin bon on mélange plusieurs trolls simultanément : plateforme vs plateforme et langage vs langage.
C'est bien pour cela que j'ai réagi à la base, on compare juste la technicité du langage, ou l'environnement complet de développement aux facilités de déploiement.
Dans les applications moderne, c'est la chaîne complète qu'on compare.
Tu prends quelques point fort de .NET et conclue .NET est meilleur.
On peut réinventer en améliorant, en faisant mieux non ?
Moi je trouve .NET mieux que Java sur certains points, certains d'entre eux ayant d'ailleur été repris par Java depuis, comme quoi c'est qu'il y avait des trucs intéressants dedans.
C'est typique des "évangélistes"
- Les autres ont copiés sur nous nos idées, on n'a pas copié les idées des autres, puisque notre roue est mieux, ce qui dénote d'une rupture technologique (hint: tout le monde se copie, ça s'appelle même le progrès).
- La techno 1 est supérieure (aujourd'hui, mais demain ça sera la techno 2 [qui peut être du même éditeur que la techno 1 !], après-demain, ça sera la techno 3, ad libitum).
Quand je lis ce genre de truc, je passe en
Je m'en tape, on compare C# et Java. Pas toto et tutu.
Je suis parti sur des exemples d'autres technologies pour être plus généraliste dans mon propos, je ne suis pas un évangéliste JAVA, je voulais juste faire l'avocat du diable.
En 2005, le Gartner Group estimait que 75% des données du monde des affaires étaient traitées par des programmes en COBOL et que 15% des nouveaux programmes développés le seront dans ce langage.
COBOL permet d'effectuer des traitements comptables du fait de ses capacités arithmétiques en virgule fixe, notamment pour les traitements par lot où il présente d'excellentes performances (on n'a pas fait mieux depuis)...
Typiquement, ça marche depuis 20ans, maintenance réduite aux migrations techniques, coût déjà amorti, pourquoi refaire dans un autre langage?
(Si un immeuble en pierre est salubre et que ces habitants vivent agréablement, faut il vraiment le refaire en béton [qui est une technique de construction supérieure au niveau technique, au niveau esthétique, c'est plutôt l'inverse] pour le refaire en "mieux").
S'il y a un type "decimal" dans C#, c'est bien pour capter ces développement de comptabilité. Ce n'est pas moi qui le dit, c'est ce que MS annonçait déjà dans .NET1.0
Ils sont évidemment utilisés dans les mêmes contextes, mais il y a des différences notables qui pour moi permettent d'être plus productif.
Je ne suis pas contre C#, mais dans tous tes exemples, on parle d'applications "lourdes" liées à l'écosystème MS.
Je l'ai déjà dit et je le répète, il ne faut pas être stupide, dans les environnements que tu décrits, .NET est évidemment le chemin de migration de moindre résistance (comme le côté obscur, plus facile, plus séduisant, plus raide, mais ce n'est pas plus puissant ^_^ [JAVA et les gros éditeurs sont pultôt du côté obscur aussi pour le développement d'application web]).
Mais ce n'est pas parce que .NET est très bien adapté dans certaines situation ou pour les projets sur lesquels tu travaillent, qu'il faut considérer .NET comme la panacée pour tous les cas.
Comme je le dis dans un autre post, à la fin du projet, ce n'est pas la technologie qui compte (sauf si c'est inmaintenable), mais si ce qui a été fait répond AU besoin concret pour lequel ça a été écrit.
Depuis le passage à LINQ, le framework de persistance BDD, le framework de collections d'objets ainsi que le moteur XML ont été bouleversés, et pour moi la productivité s'en ressent.
Typiquement, ce sont des concepts qui ont une maturation dans d'autres langages/framework que .NET et ont été repris et étendus (il me semble que la persistance BDD, ça a commencé à se diffuser d'abord avec ZODB (python), puis des personnes ont porté le concept sur JAVA, de même que RubyOnRail à pleins de clones dans les autres langages/framework maintenant que le concept à montré son efficacité).
C'est ça l'avantage de la concurrence, pour ne pas se faire dépasser les autres solutions vont adopter les mêmes idées, les pousser un peu plus loin, et ajouter de nouvelles idées.
Si .NET se fait dépasser, il reprendra les nouvelles idées et les améliorations, en ajoutera de nouvelles, et ainsi de suite.
En gros rien de nouveau sous le soleil, à part une intégration de plus en plus complète de tous les concepts.
On le voit bien au niveau OS avec la course au bling-bling et fonctionalités entre Apple et MS.
Mais c'est clair que MS fait un maximum pour faire évoluer .NET le plus rapidement possible et attirer un maximum de développeur (ça à toujours été leur stratégie d'attirer un maximum de développeur sur leur solutions) pour que ce choix s'impose naturellement par effet de masse des compétences acquises.
Techniquement, TK/Tcl est une antiquité, mais sur la facilité de créer des petites applications avec du développement light, ce n'est pas une remarque fausse.
C'est bien la technique, mais c'est un moyen, à la fin de la journée ce qui compte ce n'est pas la techno utilisée, mais est-ce que le truc développé répond AU besoin.
C'est vrai que Tk/Tcl était souple d'utilisation, mais il faut se tapper la syntaxe. En général, cette solution était utilisée pour rendre les scripts "graphiques" avec l'IHM en code Tcl/Tk et l'execution de commande lancée par la GUI.
~700 kio pour l'interpreteur+framework pour faire des programmes client qui rend naturel le passage des données sur le réseau avec d'autres clients ou services REBOL
Gros problème, ce n'est pas un langage libre, du coup ça refroidit. Il y a des bouts de code dans le monde libre, mais pas de solutions de remplacement au cas où. C'est un peu comme le langage D qui me semble intéressant, mais ne pas partager un langage, c'est un peu un non sens.
non, le but a été de tuer Java, justement.
Oui et non, quand .NET a été lancé, les applications "lourdes" java n'étaient plus vraiment une menace, il y en a, mais par rapport à leur coeur de marché, solutions OS + solutions bureautiques, Java ne les menaçaient plus.
Il faut voir qu'au même moment MacOS passait sur x86 après PPC et 68k, MS n'avait pas une telle souplesse dans le choix de leurs plate forme.
Il devenait urgent pour eux d'avoir la possibilité de s'affranchir du matériel.
Tu nous fais de la dissonance cognitive http://fr.wikipedia.org/wiki/Dissonance_cognitive
C'est de l'auto persuasion pour se dire qu'on a fait le bon choix sur des critères ~équivalents (entre 2 TV de même taille et de même prix et de performances globale équvalentes, on a choisie "la meilleure" parce que, le cadre est plus joli/design plus sobre/le temps de réponse fait 1ms de moins/...)
Je ne nie pas les avancées de C#, ni même de son utilité, ni même des avantages à avoir une syntaxe plus concise.
En fait, on se dispute sur un problème de philosphie sur le degré "d'hackitude" du langage.
JAVA est plus rigide, tout est fait pour que tu codes de manière uniforme et en évitant le plus possible les pièges conceptuels. D'où à mon regret une syntaxe super verbeuse bien indigeste à lire dans certaines parties de code technique.
A contrario, un code super compressé sur une ligne n'est pas forcément plus digeste à lire aussi (cf one liner en perl/bash/...)
Apparement, tu as été séduit par le rapport expression compressé/lisibilité du C#, mais ça ne le rend pas plus puissant intrinsèquement.
Il ne faut jamais oublier qu'à partir du moment ou un langage est "Turing complét", tu peux tout faire (plus ou moins douleureusement en fonction de la spécialisation du langage).
Event
En JAVA tu passeras par une interface, ça rendra le code encore plus lourd à lire et verbeux, mais tu auras une sécurité sur le type de fonctions et la signature à passer. C'est pour cela que JAVA a laissé tomber le pointeur sur fonction du C.
Lambda expression
Pareil, pas de vérification de contrat de signatures sur les types (philosophie non java). Néanmoins, avec les types génériques, et l'interface, je n'y ai pas réfléchi, mais il y a surement moyen de gruger (avec plus de lourdeur syntaxique, je l'accorde).
LINQ
Effectivement, je n'avais pas vu les requête sur une liste d'objet, c'est rigolo la généralisation des principes.
Honnêtement, dans mon dernier projet, les sources de données étaient en BDD, donc c'est la requête SQL qui filtrait, néanmoins, il y a eu 5 ou 6 cas en 18mois ou j'aurais apprécié le principe de LINQ pour faire des filtres sur les collections au lieu de faire une boucle ou une fonction dédiée.
Mais bien évidemment, j'ai trouvé un équivalent sous java en cherchant un peu, mais ça ne fait pas partie des librairies standard. http://quaere.codehaus.org/.
Peux tu écrire en Java un truc du style, avec typage fort, vérification par le compilo et complétion dans l'IDE
var res = from e in maListe where e.Value == 2 orderby e.Name select new {e.Id, e.Name, e.Value.ToString() }
Surement pas en une ligne, mais un code qui renvoie res avec les mêmes valeurs surement.
Franchement, des coders qui savent parfaitement utiliser la construction qui va bien dans le langage, je n'en connais pas beaucoup, surtout quand dans 90% des cas d'une application "buisness" tu va récupérer une liste, faire un filtre dessus, modifier un champs sur une ligne et réenregistrer cette ligne.
si une seule application critique est codée dans une techno MS, il est beaucoup plus pertinent d'utiliser .NET que Java pour une transition en douceur.
ça c'est n'importe quoi, ça dépend du type d'application.
Je prend un exemple extrême, mais si c'est de la réplication sur plusieurs machines et synchronisation par réseau en //, je pense qu'erlang sera beaucoup plus adapté que n'importe quel autre langage.
Deuxième contre argumentation, le choix de la nouvelle techno dépend du degré de connaissance de cette techno de ceux qui vont faire la nouvelle application. Si personne ne connait C# ni l'a mis en oeuvre, mais que ce sont tous des cadors en "autre langage", c'est "autre langage" qui te permetra une transition en douceur.
Mon but n'est pas de te convaincre d'abandonner C#, au contraire, il correspond à ton style et tu t'amuses avec, mais la liste des caractéristiques techniques d'un langage ne fait pas un programme, c'est le développeur et son degré de maitrise qui le fait.
Et quelque soit le langage, tu vas trouver des situations ou tu trouveras la syntaxe, le framework, des incohérences, bref des situations ou il sera lourdingue et CHIANT à utiliser. Dans les cas ou c'est sa force, tu trouveras le langage génial.
C'est pas 0,01%.
Je parlais du nombre de développeurs qui sauront utiliser les expressions lambda et les inférences de type (en plus C# supporte la surcharge d'opérateurs, selon le codeur, ça va vite devenir le bordel et tu seras obligé de marquer les types pour rendre le code plus lisible pour l'humain et le compilateur).
C'est super techniquement, mais pour la maintenance et les vérifications des contrats des fonctions on repassera.
LINQ :
Java Persistence Query Language (JPQL) qui provient de Hibernate Query Language (HQL)
Et pour les opérations CRUD, tu as encore plus simple JPA
event : c'est du "sucre syntaxique", c'est une bonne chose, ça rend le code moins verbeux, mais ce n'est pas un changement de paradigme.
Je ne suis pas spécialement fan de JAVA, mais les arguments avancés ne sont pas les bons pour préférer C# ou JAVA.
Il suffit que l'entreprise est un historique d'applications hétérogènes dont certaines sont écrites en VB ou en VisualC++ pour que .NET est un intérêt indéniables
Ton exemple rentre dans la catégorie entreprises 100% MS, et il ne faut pas être con, autant utiliser C#.
Maintenant mon point de vue est biaisé, je n'ai fait que des applications WEB au travail (et des scripts de conversion basiques que je peux écrire en n'importe quel language), donc l'adhérence avec un framework "bureau/application graphique" n'est pas mon soucis principal.
Et c'est la tendance en entreprise.
Maintenant, pour faire une application graphique "lourde" pour entreprise, mon choix de language/framework dépendra de l'OS (MS->.Net, Apple->Objective-C, Linux -> C++ et QT), mais pour le coup, je ne m'ennuirais surtout pas à en faire une en JAVA/SWING.
Pour un projet perso, plutôt python avec éventuellement des functions en C pour des parties de calcul critique. Je connais et je peux récupérer le code sur MS,APPLE,UNIXES
Alors si, je le dis, je trouve Mono/.NET ouachement mieux que Java, de mon point de vue.
Je ne connais pas très bien le C# en dehors de sa syntaxe de base (qui est "C like" comme le java), ce que j'en ai vu, c'est que c'est une réponse à JAVA de MS.
Le côté positif, ça a aussi accéléré le développement JAVA qui s'endormait un peu et qui a reçu un coup de pied au derrière quand MS à mis les bouchées doubles pour séduire les développeur entre la 2.0 et 3.5.
Du coup, ils se font la course, quand un des deux introduit un nouveau truc, l'autre le reprend dans la version d'après.
Après comme je le dit dans un autre post, grosso merdo c'est la même chose, les fonctionalités avancées seront utilisées par 0.01% des développeurs et les bibliothéques disponibles dans chacune des solutions couvrent les besoins application "buisness" .
Perso, je n'aime aucun des 2 langages, je les trouves trop verbeux, mais en milieux entreprise, difficile de ne pas tomber sur l'un ou l'autre des languages.
Néanmoins, pour une entreprise non spécialement MS Fan Boy, JAVA est un choix plus pérenne pour ses applications internes.
Maintenant, si je me trouvais dans une société 100% équipée MS, je partirais plutôt sur un choix .NET.
Je trouve le socle technique ouachement mieux :
...
Je trouve le hardware+assembleur vachement mieux,
- conçu multi-langages : c'est standardisé et dispo dès le départ.
- conçu pour les langages statiques et maintenant dynamiques, toujours de manière standardisé.
- conçu pour être totalement compilé : tourne par exemple sur iPhone.
- passerelle vers code natif beaucoup plus clean et simple d'utilisation que JNI.
^_^
Alternative à C# : tu n’as pas répondu. Normal, il n’y en a pas d’aussi sérieuse. Java est une grosse bouse, C++ n’a rien à voir.
Première phrase, premier Troll.
Esthétiquement, on peut préférer .NET ou JAVA pour la syntaxe et les noms des libs, mais grosso-merdo, ils ont les mêmes limites et les mêmes concepts.
Alternative à CLI : les JVM, avec toutes leurs subtiles incompatibilités.
Je ne veux pas dire, mais travaillant sur JAVA depuis 2000 surtout dans les applis web.
Dans ce cadre là, j'ai rencontré 2 cas, ou il fallait recompiler les jar sur la plate-forme de production, parce qu'on avait pas une JVM du même éditeur sur les postes développeurs, et encore c'était en 2001-2002 avant que la norme J2EE soit mieux respectée.
Alternative à .Net :
Il faut bien comprendre que MS à commencer a pousser .NET quand Linux est devenu une menace plus sérieuse pour eux dans la mesure ou Linux n'est pas limité au x86 pour les applications dont on dispose le source.
Pour distribuer un "binaire" tout en étant indépendant du matériel sous jacent, il faut une VM.
Il y a quelques années, MS annonçait de migrer toutes leurs applications sous .NET pour être indépendant du matériel.
Je constate que depuis que les technologies de virtualisation sont plus courantes, MS se fait plus discret sur cette migration.
Autrement pour Python, je suis d'accord, j'adore ce langage, mais il manque une certaine cohérence pour le choix d'une bibliothèque.
mais si aujourd’hui je devais concevoir une nouvelle application de plus de quelques milliers de lignes de code,
Si les gros éditeurs décidaient du jour au lendemain de basculer tout en Python/Ruby/OCAML/Lisp/Haskell/..., tu aurais exactement les outils qu'ils te manquent à l'heure actuelle qui accompagnerait ce nouveau choix "industriel"
Pour faire des applications "professionnelles" (c'est à dire développé pour une entreprise par elle même ou une société de service), il faut une taylorisation des moyens pour interchanger les développeurs entre projets. Donc il faut pouvoir tenir les développeurs par la main.
Forcément le monde du libre, c'est la liberté de faire ses propres choix, c'est moins cadré.
Le rapport, c'est que les deux ouvrent une fenêtre ou on tape du texte dedans :-)
Blague à part, 14.9MiB pour Gnotes (hors librairies partagées), Tomboy est plus gros de ~8Mib (~23Mib), ça devient vraiment du n'importe quoi pour la gestion des ressources.
Ce ne sont pas les ~200 caractères par notes qui vont aller occuper entre 15 et 20Mib de mémoire vive.
Et pourtant, quand je programme en Python ou Java, je suis le premier à laisser le GB à se débrouiller tout seul (en dehors de d'ajouter variable=null; pour faciliter son travail) à utiliser les fonctions HashMap ou Listes qui doivent bien occuper x fois plus de mémoire qu'un tableau d'octets gérée à la mimine.
Mais x doit surement être inférieur à 10 à la méga louche.
Ok, on a des Gib, mais sans vouloir optimiser en assembleur, il y a une différence entre choisir le mauvais algorithme (occupation mémoire) et un algorithme plus adapté par définition.
C'est exactement le même débat avec la vitesse, ça ne sert à rien de programmer un tri à bulle en assembleur quand un shell sort même en basic sera plus rapide sur des millions d'éléments.
Après il y a les buffers écrans, une zone 640x512 en 24bits, c'est un buffer de ~1Mib, ce buffer est pris du côté de X11 ou de l'application ? (si c'est du côté de X11, c'est pire que j'imaginais).
Dans ce cas là, je traduirais plutôt par :
"conception par motif" (qui n'a pas d'équivalent dans un autre domaine pour son utilisation en français)
qui est plus long à dire que "Design Pattern" (qui en plus a un bonus d'attaque pipo-bimbo marketing).
Du coup, "Design Pattern" est plus adapté, plus rapide à prononcer, plus "decision manager compliant", ...
Autant "baladeur" est une traduction agréable de "walkman", "Cédérom" c'est déjà moins évident pour "CD".
J'utilise systématiquement courriel (courrier éléctronique <-> electronic mail) parce que l'idée est toujours présente et que le mot est "esthétique" à la prononciation.
Je suis à 100% pour la francisation des termes, s'ils veulent dire quelque chose.
Les anglais pourraient aussi traduire "cul de sac" (pour impasse) en "buttbag" à ce moment là :-D
Par contre, je ne comprends pas trop pourquoi tu pense que la fréquence de "rafraîchissement" est importante pour un LCD, a priori hormis pour les animations cela ne devrait pas avoir d'importance.
Tout changement d'une partie de l'écran est une animation (curseur, défilement fenêtre avec les ascenseurs,...). ça ne se limite pas aux vidéos ou jeux.
Dans le cas de suivre le curseur souris ou de suivre un texte que l'on fait défiler.
Quand le déplacement est fluide (ce qui dépend de la fréquence de rafraîchissement et aussi d'un truc bien programmé sur un processeur non asthmatique), le cerveau pré-positionne les globes oculaires par interpolations et fait une recherche locale pour trouver le curseur/mot.
Quand le déplacement est saccadé (fréquence de rafraîchissement faible et/ou truc programmé avec les pieds sur une antiquité), le cerveau pré-positionne toujours les globes oculaires par interpolation, mais comme il y a moins de valeurs, sa marge d'erreur sera plus grande, la recherche deviendra plus globale (mouvements oculaires beaucoup plus large) pour trouver le curseur/mot.
ça ne vous arrive jamais de perdre le curseur des yeux après un mouvement de souris trop rapide ?
P.S. désolé pour le double post, mais le premier n'apparaît pas sur mon ordinateur.
Par contre, je ne comprends pas trop pourquoi tu pense que la fréquence de "rafraîchissement" est importante pour un LCD, a priori hormis pour les animations cela ne devrait pas avoir d'importance..
Pour des questions de persistances rétiniennes comme pour le CRT, même si les pixels restent allumés, au moment du rafraîchissement, si une zone importante de l'écran change, tu verras des décalages (impressions de saccades lors d'un défilement de texte par exemple).
Tout ce qui est saccades fatigue, il faut replacer les globes oculaires sur le mot qui était visé avant le défilement et faire travailler plus activement le cerveau pour qu'il puisse repérer de nouveau ce même mot.
Si le mouvement est fluide, le cerveau positionnera les yeux par interpolation.
Donc tout changement de zone est une animation (curseur souris, défilement fenêtre) et ne se limite pas aux jeux ou vidéos.
Sur un LCD, je préfère du texte NOIR sur fond BLANC (vu que le noir est un blocage de blanc sur LCD). La stabilité d'affichage du LCD et le fait de baisser la luminosité permet d'arriver plus prêt d'un résultat papier et de ne pas (trop) fatiguer les yeux.
Sur un CRT en mode texte, je préfère texte DEMI-BLANC (ou DEMI-VERT/AMBRE à la rigueur ) sur fond NOIR (vu que le noir, c'est moins d'électrons dans la gueule sur un CRT).
La clef de la fatigue visuelle vient de la luminosité et de la fréquence de raraichissemment qui doit être minimum 60hz sur un LCD et minimum 85hz (->100/120hz) sur un CRT (pour que l'image s'affiche plusieurs fois sur la rétine avant la fine de la persitence rétinienne).
Actuellement, je ne travaille plus que sur LCD, et je passe plus de 8h par jour devant un écran.
Ce qui est rigolo avec un CRT, c'est que sur mon amiga le 640x512@25hz faisait pleurer, quand j'utilisais un PC en VGA 640x480@60, je trouvais ça trop stable et trop reposant, et maintenant à moins de 75hz, je vois l'écran clignoter et je trouve ça trop fatiguant.
L'installeur est aussi en alpha, à plusieurs étapes, l'écran bloque avant de passer à l'étape suivante. Au début, j'ai cru que ça venait de ma clef USB est à moitié pourri sur les blocs, mais la version CD me faisait les mêmes coups aux mêmes endroits.
Une petite remarque acerbe, lors de la création des points de montage, il n'est pas possible de définir plus d'un point de montage autre que les points de montages standards (/, /boot, /usr, /home, /etc, ...) et il y a un bug quand on a plusieurs disques, passer de l'un à l'autre finit par provoquer un freeze de l'installeur après un A/R
Une fois l'installation effectuée, c'est très joli et cohérent.
En plus je suis un anti-KDE (en ce moment un gnomiste par défaut), car je trouvais qu'il y avait vraiment trop de trucs installés par défaut et l'IHM KDE avec trop de réglages me convenait moins que pour gnome qui a peu de réglage et des réglages bizarres.
A vrai dire, ce qui m'a le plus impressionné, c'est que mon opteron 1,8ghz** semble avoir retrouvé une seconde jeunesse alors que ma Ubuntu 8.10 semblait ramer de plus en plus jour après jour (syndrome windosien ?).
Avant j'étais sous gentoo et fluxbox (barebone PIV@2ghz), mais j'en ai eu marre de passer plus de temps à paramétrer mon système que l'utiliser (et si j'enléve ce USE flag, je vais peut être gagner encore un peu de CPU), bien que cet effort me permetait d'avoir une machine réactive par rapport à une distribution binaire (qui compile les paquets avec toutes les options.
Et bien Chakra me redonne cette impression, et ce sont d'autres personnes qui font tout le boulot à ma place :-D
Par contre, la mise à jour automatique s'est vautré et le processus s'est retrouvé dans un état occupé mais sans bosser !
Il y a 4 desktop activés, mais pas de gadget pour passer de l'un à l'autre.
Bon j'avoue, je n'ai pas trop creusé, il manque encore pleins de détails, mais le socle est bon, j'attend de voir l'alpha4 ou la béta pour retenter l'aventure et virer ubuntu de mon DD.
** Je peux l'overclocker à 2,6 sans pb, mais j'ai un scythe de 953g sur le proc + carte gfx et alimentation passives. J'ai quand même du mettre un noctua 12db au cul pour créer un courrant d'air minimum dans le boitier, autrement la chaleur stagne.
Résultat des courses, le seul bruit que je perçois est la tête du disque dur quand elle gratte. Entre le confort de silence et la vitesse, j'ai vite choisi.
C'est pareil en France, il suffit de prendre le texte et :
s/chine/france/i
s/chinois/français/i
s/parti communiste/[parti politique français eu pouvoir (par rotation)]/
Et tu as exactement la même situation dans les administrations Françaises un peu noyauté par le népotisme et le clientélisme.
Quand on lis que l'appel d'offre d'HADOPI a été lancé avant même que la loi soit présenté au parlement ! je me demande bien quel copain a eu le contrat.
Linux est devenu pourri. Les applis moisies. Merci Apple. Pour le fun, le gain de temps et la productivité que tu m'as apporté.
Le jugement est un peu dur. On n'aime ou pas le style ubuntu, mais indubitablement cette distribution est utilisable avec zero connaissances en dehors de la manipulation de la souris et du clavier.
Pour les applications "pourris", dans 95% des utilisations, les gens n'utilisent pas les fonctionalitées qui font les différences entre un logiciel pro et un logiciel amateur.
Donc pour le pro, ces fonctionalités plus policés lui font gagner du temps de travail, mais in fine, ce n'est pas l'outil qui compte, c'est ce qu'on en fait. Et puis Apple est justement là pour remplir cette niche.
Ce qui est marrant, c'est que je n'ai pas d'apriori contre Apple et je trouve leur design vraiment sympa, mais je ne supporte pas de travailler sur ce système parce que je le trouve trop "neuneu" dans l'ergonomie pour qu'il n'y ait pas de confusion possible dans l'esprit de l'utilisateur.
- La souris 1 bouton, obligé d'utiliser 2 mains pour avoir un menu contextuel
- Les animations qui durent ~1s (exemple d'ouverture et de fermeture de fenêtre), et ça depuis le système 6.
- Les menus coincés dans la barre d'outils du haut
et pleins de petits détails dans ce style.
Le tout me donne l'impression d'être sur un paquebot de luxe où je crie les ordres dans un tube qui sont ensuite executé par la salle de machines contrairement à un OS plus réactif ou on tient directement la barre.
Je comprend la philosophie d'Apple, mais j'aime pas être pris par la main quand je suis sur un ordinateur. En plus je trouve que tous ces délais ralentissent le flux de travail in fine.
Chacun ses goûts.
ça pourrait passer pour un troll, mais non, je m'explique.
En discutant avec mes parents, la famille et les personnes de leur générations, ils trouvent l'utilisation de l'informatique trop compliquée, car cela fait appel à beaucoup de mémorisation visuelle et une capacité à être curieux et cliquer partout dans le "clickodrome" pour trouver la fonction que l'on recherche (ils ne sont pas de la génération "zapping").
Ayant eu une formation plus "scolaire" enfants et un travail plus par le texte que l'image dans leur vie professionnelle, ils préfèrent avoir une procédure écrite sur les actions à enchainer pour faire une action.
Seulement avec les interfaces graphiques, les options changent de place d'une versions à l'autre, il y a beaucoup d'éléments visuels (la vue deviens généralement moins bonne au cours des années) et les applications peuvent s'ouvrir à différents endroits sur l'écran.
Beaucoup d'élément qui nécessite une plus grande plasticité mentale.
D'autant plus que la plupart s'y sont mis "la tête sur le billot", car c'était l'ordinateur et le courriel pour voir les photos des petits enfants ou plus de photos du tout !!
Ils ont plus de difficultés à retenir et pas vraiment de motivation pour apprendre (je ne parle pas des passionnés que l'on peut rencontrer à tout age et dans tous les domaines), ce qui les fait repartir plus ou moins à zéro à chaque utilisation (après 8 ans, mon père n'a toujours pas voulu associer le mot "touche entrée" à la touche entrée [elle est où ?], parce que ce n'est pas marqué dessus sur son clavier, et au boulot dans les années 80 il travaillait déjà sur un clavier, et ce n'est pas le seul de sa génération à NE PAS VOULOIR RETENIR, ça ne les intéresse pas, seul le contact familial les intéresse).
Finalement, faire une lettre en TeX sera plus simple pour eux s'ils ne sortent pas du modèle par défaut, certe, ce n'est plus wysiwyg, mais l'enchainement des commandes est visible, donc il n'ont pas à interpréter les réactions de l'éditeur de texte quand un style ne veut pas disparaître (ex une phrase en gras, suppression de la phrase, mais quand la personne retappe, le style gras est toujours selectionné).
De même pour toute autre activité, cela sera plus simple de lire un document papier qui explique étape par étape les commandes a effectuer.
Pas de réflexions, on applique bêtement les procédures.
Malheureusement, je n'ai pas le temps, ni l'envie d'ailleurs de me faire des scénarios de cas d'utilisation pour leur écrire ce genre de procédures.
Mais il y a un besoin réel, en dehors des personnes motivées, je n'ai rencontré personne qui soit un peu agé qui était content des IHM actuelle, et les effets 3D et toussa ça leur passe à une altitude stratosphérique au dessus de leur tête.
Pour conclure, la ligne de commande n'est pas user friendly si on ne sait pas ce que l'on fait car on doit apprendre la syntaxe.
Ecrire dans une langue étrangère, c'est dur, recopier un texte d'une langue étrangère, c'est simple.
Voilà pourquoi les discussions sur les lignes de commandes partent en Troll systèmatiques.
Plantages à cause de la 3D... je n'en connais pas depuis que j'utilise des cartes Intel.
Il n'y a peut-être plus de plantage X ou linux pour les chipsets intel, mais les bugs d'affichage sont encore présent.
J'ai acheté il y a 6 mois un ordinateur CM chipset intel gfx intégré avec dual-core, et tout marche nickel sous Ubuntu, sauf Google-earth qui pour une raison inconnue à pleins de bugs graphiques (textures vertes et mauves en rayure verticale, ordre d'affichage inverse des polygones, transparence foireuse, ....) et la dernière mise à jour n'a rien changé.
Du coup, je suis refroidi pour m'acheter une CM avec chipset intel, vu que la compatibilité ave linux assurée par les drivers libres, toussa... n'est pas "au top".
C'est pour ça que je suis super interessé par la carte OGD, car je suis quasiment certains que ce genre de bugs d'affichage sera corrigé super rapidement par un hacker du système qui ne va pas supporter longtemps ce "genre de conneries" contrairement à un support plus commercial qui va peut-être éventuellement prendre en compte le bug dans un méga cycle en V.
Même à 200€ je suis preneur, je préfère la stabilité et la revue de code. D'ailleurs j'ai une Nvidia 7600 (c'est pas une foudre de guerre) dans ma machine, et ce qui fait sa force ce sont ses drivers par rapports aux autres solution sous linux (ATI il y a quelques années, Intel récemment).
J'avoue que sans windows depuis 5 ans et n'étant pas joueur (du casual gaming de temps en temps), c'est plus facile pour moi de dire ça.
Et puis avec tous les gouvernements qui se demandent comment ils vont reprendre le contrôle du net avec des lois liberticides et la quasi obligation de prendre des solutions propriétaires, il faut absolument qu'on ait du hard libre, même décalé de 10ans (génération PII-PIII) en performances (fondamentalement depuis 1993, je fais toujours du courriel, du web, écrire une lettre administrative, coder, écouter de la musique sur mon ordi) avant de se faire totalement enfermer.
D'ailleurs je suis de près le projet NATAMI http://www.natami.net/ qui veut faire un nouvel "amiga" compatible AGA (+3D,son 16bits,...) avec des perfs équivalentes à un Pentium-MMX+Voodoo1 sur un FPGA et je me suis déjà demandé si la carte OGD ne pouvait pas être utilisé pour tester ce genre d'idée à moindre coût.
Ce genre de puissance suffit pour une usage courant, on pourra peut-être bientôt s'affranchir des constructeurs et du bagage de la compatibilité ascendante imposée par la distribution en binaire des OS et des applications.
De ce point de vue-là, PowerShell n'est pas du tout un concurrent de Bash, de Zsh, de Tcsh ou autre, mais plutôt de Python ou de Perl. Ou peut-être quelque chose d'un nouveau genre.
Je dirais effectivement un nouveau genre, c'est la reunion d'un veritable langage de programmation avec un shell et un framework.
Powershell n'est pas non plus le dernier truc qui fait le café.
Par exemple, la réunion d'un langage de programmation et d'un shell existe déjà pour Perl avec psh http://www.focusresearch.com/gregor/sw/psh/
psh is a Perl program which executes a read-eval loop with enough options so that general behavior reasonably similar to more traditional shells like 'sh' or 'bash' can be achieved, while still allowing arbitrary perl expressions to be evaluated.
Il me semble qu'il y a un équivalent sous python, mais une recherche rapide n'a rien donné.
Le principe n'est pas nouveau, Rexx (ARexx pour moi car j'étais amigaïste) est encore plus vieux sur ce principe, permettant même aux programmes GUI d'exposer leur fonctionalité en créant une API port Rexx, ce qui les transformait en utilitaire "shell" pour automatiser les traitements en externalisant les scripts (contrairement à la tendance actuelle d'intégrer l'édition de script dans les programmes eux-même)
Le problème de tous ces hybrides, c'est qu'il faut apprendre le langage (et surtout la librairie qui va avec), alors que les commandes unix permettent de faire une chose et une seule facilement.
Le seul interêt d'un shell est de rentrer les directives de manière interactive orientées manipulation fichier (pas de commande "open file", "close file" à ajouter dans le code)
Un shell unix avec ses outils de base, tu peux déjà faire pas mal d'opération par rapport à un cmd.exe. Que je me connecte à un linux (défaut bash), un serveur AIX (défaut ksh), HP ou SUN, BSD, Darwin, j'ai toujours le même écosytéme de commandes (il y a des pièges parfois sur des différences d'option) qui permettent de couvrir beaucoup de cas courant de manipulation simple, et certains outils comme netcat sont vraiment géniaux (par exemple pour lire un film sur un ordinateur distant sans créer de partage réseau ou copier le fichier du film au préalable).
Et si j'en crois le site de microsoft http://www.microsoft.com/windowsserver2003/technologies/mana(...) , powershell est installé par défaut uniquement à partir de la version server 2008 (même si on pouvait la télécharger et l'installer à partir de XP).
Mieux vaut tard que jamais, mais on ne peut pas espérer se connecter sur une machine windows hors server 2008 et être sûr d'avoir un powershell à sa disposition.
Dans quelques années, la question ne se posera peut être plus, mais pour l'instant, ce n'est qu'une option.
Ce qui n'enléve rien aux possibilités de powershell et que c'est un bon de géant en avant pour les administrateurs windows par rapport à cmd.exe
Le but recherché entre shell et powershell n'est pas le même.
Le jour ou on trouvera en standard grep, awk, sed, md5sum, sha1sum, wget, wput, wc, mail, sendmail, bzip2, less, more, gzip, lzma, tar, cut, tail, head, su, sudo, at, find, zip, bc, base64, netcat, diff, patch, ln, mkfifo, cat, ssh, scp, sftp, gpg, uniq et xargs, on en reparlera, d'accord ?
Il y a boire et à manger dans cette liste, tu mélange pêle mêle, manipulation de fichiers, outils de compressions, et outils réseaux.
ça dépend de l'usage de chacun, faut pas déconner (et je suis 100% linux chez moi). Il y en a marre de se payer des outils antediluvien sous pretexte qu'ils sont "essentiels" alors que la vraie raison, c'est que des générations d'admin ont fait des scripts illisibles avec.
En plus un bash, c'est plus d'un méga en mémoire au lancement, quand on voit la faune des scripts de démarrage sous linux, et que ce mécanisme a très peu évolué, on peut se poser des questions sur les non-performances entrainées au boot.
Un système écrit sur un langage plus évolué avec une seule VMbytecode serait plus light en ressources et plus rapide.
xargs est une vaste blague, c'est une commande qui a été crée après coup pour pouvoir récupérer les argument à travers un pipe, et comme elle n'a jamais évoluée, quand tu as un espace dans tes noms de fichiers (maintenant j'utilise des espaces dans mes noms de fichiers), ça te fait planter ton beau one-liner.
Au boulot, j'utilise cygwin pour avoir des commandes unix, et comme en général, c'est pour analyser des logs, ou trouver des méthodes, mon outil numéro est "grep" (plus rapide que "rechercher" windows).
Autant j'apprécie le fait d'avoir ces commandes pour rapidement filtrer des fichiers pour trouver le problème à la main qui m'intéresse, autant si je devais automatiser une chaîne de traitement, je ne la ferais pas en sh/csh/ksh/bash (je dis ça parce que tu cites AWK, et tu ne crée pas un filtre AWK pour le plaisir par exemple)
Avec ces outils, tu te retrouves avec trop de problèmes avec les séparateurs (espace tabulation) pour faire des solutions robuste.
Si ce que je dis était faux, PERL n'aurait pas eu autant de succès, car il comble beaucoup de manque de la programmation shell où ce n'est pas intuitif (arithmétique, somme des lignes de plusieurs fichiers par exemples, collections/tableaux, ...)
Les commande unix de BASE (au sens unix d'une commande qui ne fait qu'une seule chose mais qui la fait bien), mangez en, autant il ne faut pas s'arcbouter religieusement dessus.
Maintenant la ligne de commande "dos", c'est pire, maintenant je ne connais pas le powershell.
P.S. dd est effectivement une commande essentielle de mon toolkit pour récupérer une image disk ou au contraire éclater en DUR la table des partitions rapidement.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 2.
...
Je trouve le socle technique ouachement mieux :
Je trouve le langage C# ouachement mieux que le langage Java : event, property, linq, lambda, inférence de type, etc.
...
Après tu trouveras sûrement tout ça ailleur, mais pas ensemble : et moi c'est tout ca sur la même plateforme qui la rend sexy. Et c'est pour la même raison que beaucoup de développeurs utilisent Mono.
m'enfin bon on mélange plusieurs trolls simultanément : plateforme vs plateforme et langage vs langage.
C'est bien pour cela que j'ai réagi à la base, on compare juste la technicité du langage, ou l'environnement complet de développement aux facilités de déploiement.
Dans les applications moderne, c'est la chaîne complète qu'on compare.
Tu prends quelques point fort de .NET et conclue .NET est meilleur.
On peut réinventer en améliorant, en faisant mieux non ?
Moi je trouve .NET mieux que Java sur certains points, certains d'entre eux ayant d'ailleur été repris par Java depuis, comme quoi c'est qu'il y avait des trucs intéressants dedans.
C'est typique des "évangélistes"
- Les autres ont copiés sur nous nos idées, on n'a pas copié les idées des autres, puisque notre roue est mieux, ce qui dénote d'une rupture technologique (hint: tout le monde se copie, ça s'appelle même le progrès).
- La techno 1 est supérieure (aujourd'hui, mais demain ça sera la techno 2 [qui peut être du même éditeur que la techno 1 !], après-demain, ça sera la techno 3, ad libitum).
Quand je lis ce genre de truc, je passe en
Je m'en tape, on compare C# et Java. Pas toto et tutu.
Je suis parti sur des exemples d'autres technologies pour être plus généraliste dans mon propos, je ne suis pas un évangéliste JAVA, je voulais juste faire l'avocat du diable.
[^] # Avec une argumentation comme ça, on aurait tous du rester au COBOL.
Posté par darkleon (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 2.
En 2005, le Gartner Group estimait que 75% des données du monde des affaires étaient traitées par des programmes en COBOL et que 15% des nouveaux programmes développés le seront dans ce langage.
COBOL permet d'effectuer des traitements comptables du fait de ses capacités arithmétiques en virgule fixe, notamment pour les traitements par lot où il présente d'excellentes performances (on n'a pas fait mieux depuis)...
Typiquement, ça marche depuis 20ans, maintenance réduite aux migrations techniques, coût déjà amorti, pourquoi refaire dans un autre langage?
(Si un immeuble en pierre est salubre et que ces habitants vivent agréablement, faut il vraiment le refaire en béton [qui est une technique de construction supérieure au niveau technique, au niveau esthétique, c'est plutôt l'inverse] pour le refaire en "mieux").
S'il y a un type "decimal" dans C#, c'est bien pour capter ces développement de comptabilité. Ce n'est pas moi qui le dit, c'est ce que MS annonçait déjà dans .NET1.0
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 3.
Je ne suis pas contre C#, mais dans tous tes exemples, on parle d'applications "lourdes" liées à l'écosystème MS.
Je l'ai déjà dit et je le répète, il ne faut pas être stupide, dans les environnements que tu décrits, .NET est évidemment le chemin de migration de moindre résistance (comme le côté obscur, plus facile, plus séduisant, plus raide, mais ce n'est pas plus puissant ^_^ [JAVA et les gros éditeurs sont pultôt du côté obscur aussi pour le développement d'application web]).
Mais ce n'est pas parce que .NET est très bien adapté dans certaines situation ou pour les projets sur lesquels tu travaillent, qu'il faut considérer .NET comme la panacée pour tous les cas.
Comme je le dis dans un autre post, à la fin du projet, ce n'est pas la technologie qui compte (sauf si c'est inmaintenable), mais si ce qui a été fait répond AU besoin concret pour lequel ça a été écrit.
Depuis le passage à LINQ, le framework de persistance BDD, le framework de collections d'objets ainsi que le moteur XML ont été bouleversés, et pour moi la productivité s'en ressent.
Typiquement, ce sont des concepts qui ont une maturation dans d'autres langages/framework que .NET et ont été repris et étendus (il me semble que la persistance BDD, ça a commencé à se diffuser d'abord avec ZODB (python), puis des personnes ont porté le concept sur JAVA, de même que RubyOnRail à pleins de clones dans les autres langages/framework maintenant que le concept à montré son efficacité).
C'est ça l'avantage de la concurrence, pour ne pas se faire dépasser les autres solutions vont adopter les mêmes idées, les pousser un peu plus loin, et ajouter de nouvelles idées.
Si .NET se fait dépasser, il reprendra les nouvelles idées et les améliorations, en ajoutera de nouvelles, et ainsi de suite.
En gros rien de nouveau sous le soleil, à part une intégration de plus en plus complète de tous les concepts.
On le voit bien au niveau OS avec la course au bling-bling et fonctionalités entre Apple et MS.
Mais c'est clair que MS fait un maximum pour faire évoluer .NET le plus rapidement possible et attirer un maximum de développeur (ça à toujours été leur stratégie d'attirer un maximum de développeur sur leur solutions) pour que ce choix s'impose naturellement par effet de masse des compétences acquises.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 5.
C'est bien la technique, mais c'est un moyen, à la fin de la journée ce qui compte ce n'est pas la techno utilisée, mais est-ce que le truc développé répond AU besoin.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 2.
Un truc moderne qui a le meilleur rapport puissance/code/portabilité, c'est REBOL
http://www.rebol.com/prod-view.html
http://rebolzone.free.fr/rbpresentation.php
~700 kio pour l'interpreteur+framework pour faire des programmes client qui rend naturel le passage des données sur le réseau avec d'autres clients ou services REBOL
Quelques programmes d'exemples
http://www.rebol.com/pre-view.html
Gros problème, ce n'est pas un langage libre, du coup ça refroidit. Il y a des bouts de code dans le monde libre, mais pas de solutions de remplacement au cas où. C'est un peu comme le langage D qui me semble intéressant, mais ne pas partager un langage, c'est un peu un non sens.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 1.
Oui et non, quand .NET a été lancé, les applications "lourdes" java n'étaient plus vraiment une menace, il y en a, mais par rapport à leur coeur de marché, solutions OS + solutions bureautiques, Java ne les menaçaient plus.
Il faut voir qu'au même moment MacOS passait sur x86 après PPC et 68k, MS n'avait pas une telle souplesse dans le choix de leurs plate forme.
Il devenait urgent pour eux d'avoir la possibilité de s'affranchir du matériel.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 4.
http://fr.wikipedia.org/wiki/Dissonance_cognitive
C'est de l'auto persuasion pour se dire qu'on a fait le bon choix sur des critères ~équivalents (entre 2 TV de même taille et de même prix et de performances globale équvalentes, on a choisie "la meilleure" parce que, le cadre est plus joli/design plus sobre/le temps de réponse fait 1ms de moins/...)
Je ne nie pas les avancées de C#, ni même de son utilité, ni même des avantages à avoir une syntaxe plus concise.
En fait, on se dispute sur un problème de philosphie sur le degré "d'hackitude" du langage.
JAVA est plus rigide, tout est fait pour que tu codes de manière uniforme et en évitant le plus possible les pièges conceptuels. D'où à mon regret une syntaxe super verbeuse bien indigeste à lire dans certaines parties de code technique.
A contrario, un code super compressé sur une ligne n'est pas forcément plus digeste à lire aussi (cf one liner en perl/bash/...)
Apparement, tu as été séduit par le rapport expression compressé/lisibilité du C#, mais ça ne le rend pas plus puissant intrinsèquement.
Il ne faut jamais oublier qu'à partir du moment ou un langage est "Turing complét", tu peux tout faire (plus ou moins douleureusement en fonction de la spécialisation du langage).
Event
En JAVA tu passeras par une interface, ça rendra le code encore plus lourd à lire et verbeux, mais tu auras une sécurité sur le type de fonctions et la signature à passer. C'est pour cela que JAVA a laissé tomber le pointeur sur fonction du C.
Lambda expression
Pareil, pas de vérification de contrat de signatures sur les types (philosophie non java). Néanmoins, avec les types génériques, et l'interface, je n'y ai pas réfléchi, mais il y a surement moyen de gruger (avec plus de lourdeur syntaxique, je l'accorde).
LINQ
Effectivement, je n'avais pas vu les requête sur une liste d'objet, c'est rigolo la généralisation des principes.
Honnêtement, dans mon dernier projet, les sources de données étaient en BDD, donc c'est la requête SQL qui filtrait, néanmoins, il y a eu 5 ou 6 cas en 18mois ou j'aurais apprécié le principe de LINQ pour faire des filtres sur les collections au lieu de faire une boucle ou une fonction dédiée.
Mais bien évidemment, j'ai trouvé un équivalent sous java en cherchant un peu, mais ça ne fait pas partie des librairies standard.
http://quaere.codehaus.org/.
Peux tu écrire en Java un truc du style, avec typage fort, vérification par le compilo et complétion dans l'IDE
var res = from e in maListe where e.Value == 2 orderby e.Name select new {e.Id, e.Name, e.Value.ToString() }
Surement pas en une ligne, mais un code qui renvoie res avec les mêmes valeurs surement.
Franchement, des coders qui savent parfaitement utiliser la construction qui va bien dans le langage, je n'en connais pas beaucoup, surtout quand dans 90% des cas d'une application "buisness" tu va récupérer une liste, faire un filtre dessus, modifier un champs sur une ligne et réenregistrer cette ligne.
si une seule application critique est codée dans une techno MS, il est beaucoup plus pertinent d'utiliser .NET que Java pour une transition en douceur.
ça c'est n'importe quoi, ça dépend du type d'application.
Je prend un exemple extrême, mais si c'est de la réplication sur plusieurs machines et synchronisation par réseau en //, je pense qu'erlang sera beaucoup plus adapté que n'importe quel autre langage.
Deuxième contre argumentation, le choix de la nouvelle techno dépend du degré de connaissance de cette techno de ceux qui vont faire la nouvelle application. Si personne ne connait C# ni l'a mis en oeuvre, mais que ce sont tous des cadors en "autre langage", c'est "autre langage" qui te permetra une transition en douceur.
Mon but n'est pas de te convaincre d'abandonner C#, au contraire, il correspond à ton style et tu t'amuses avec, mais la liste des caractéristiques techniques d'un langage ne fait pas un programme, c'est le développeur et son degré de maitrise qui le fait.
Et quelque soit le langage, tu vas trouver des situations ou tu trouveras la syntaxe, le framework, des incohérences, bref des situations ou il sera lourdingue et CHIANT à utiliser. Dans les cas ou c'est sa force, tu trouveras le langage génial.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 1.
Je parlais du nombre de développeurs qui sauront utiliser les expressions lambda et les inférences de type (en plus C# supporte la surcharge d'opérateurs, selon le codeur, ça va vite devenir le bordel et tu seras obligé de marquer les types pour rendre le code plus lisible pour l'humain et le compilateur).
C'est super techniquement, mais pour la maintenance et les vérifications des contrats des fonctions on repassera.
LINQ :
Java Persistence Query Language (JPQL) qui provient de Hibernate Query Language (HQL)
Et pour les opérations CRUD, tu as encore plus simple JPA
event : c'est du "sucre syntaxique", c'est une bonne chose, ça rend le code moins verbeux, mais ce n'est pas un changement de paradigme.
Je ne suis pas spécialement fan de JAVA, mais les arguments avancés ne sont pas les bons pour préférer C# ou JAVA.
Il suffit que l'entreprise est un historique d'applications hétérogènes dont certaines sont écrites en VB ou en VisualC++ pour que .NET est un intérêt indéniables
Ton exemple rentre dans la catégorie entreprises 100% MS, et il ne faut pas être con, autant utiliser C#.
Maintenant mon point de vue est biaisé, je n'ai fait que des applications WEB au travail (et des scripts de conversion basiques que je peux écrire en n'importe quel language), donc l'adhérence avec un framework "bureau/application graphique" n'est pas mon soucis principal.
Et c'est la tendance en entreprise.
Maintenant, pour faire une application graphique "lourde" pour entreprise, mon choix de language/framework dépendra de l'OS (MS->.Net, Apple->Objective-C, Linux -> C++ et QT), mais pour le coup, je ne m'ennuirais surtout pas à en faire une en JAVA/SWING.
Pour un projet perso, plutôt python avec éventuellement des functions en C pour des parties de calcul critique. Je connais et je peux récupérer le code sur MS,APPLE,UNIXES
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 4.
Je ne connais pas très bien le C# en dehors de sa syntaxe de base (qui est "C like" comme le java), ce que j'en ai vu, c'est que c'est une réponse à JAVA de MS.
Le côté positif, ça a aussi accéléré le développement JAVA qui s'endormait un peu et qui a reçu un coup de pied au derrière quand MS à mis les bouchées doubles pour séduire les développeur entre la 2.0 et 3.5.
Du coup, ils se font la course, quand un des deux introduit un nouveau truc, l'autre le reprend dans la version d'après.
Après comme je le dit dans un autre post, grosso merdo c'est la même chose, les fonctionalités avancées seront utilisées par 0.01% des développeurs et les bibliothéques disponibles dans chacune des solutions couvrent les besoins application "buisness" .
Perso, je n'aime aucun des 2 langages, je les trouves trop verbeux, mais en milieux entreprise, difficile de ne pas tomber sur l'un ou l'autre des languages.
Néanmoins, pour une entreprise non spécialement MS Fan Boy, JAVA est un choix plus pérenne pour ses applications internes.
Maintenant, si je me trouvais dans une société 100% équipée MS, je partirais plutôt sur un choix .NET.
Je trouve le socle technique ouachement mieux :
...
Je trouve le hardware+assembleur vachement mieux,
- conçu multi-langages : c'est standardisé et dispo dès le départ.
- conçu pour les langages statiques et maintenant dynamiques, toujours de manière standardisé.
- conçu pour être totalement compilé : tourne par exemple sur iPhone.
- passerelle vers code natif beaucoup plus clean et simple d'utilisation que JNI.
^_^
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 7.
Première phrase, premier Troll.
Esthétiquement, on peut préférer .NET ou JAVA pour la syntaxe et les noms des libs, mais grosso-merdo, ils ont les mêmes limites et les mêmes concepts.
Alternative à CLI : les JVM, avec toutes leurs subtiles incompatibilités.
Je ne veux pas dire, mais travaillant sur JAVA depuis 2000 surtout dans les applis web.
Dans ce cadre là, j'ai rencontré 2 cas, ou il fallait recompiler les jar sur la plate-forme de production, parce qu'on avait pas une JVM du même éditeur sur les postes développeurs, et encore c'était en 2001-2002 avant que la norme J2EE soit mieux respectée.
Alternative à .Net :
Il faut bien comprendre que MS à commencer a pousser .NET quand Linux est devenu une menace plus sérieuse pour eux dans la mesure ou Linux n'est pas limité au x86 pour les applications dont on dispose le source.
Pour distribuer un "binaire" tout en étant indépendant du matériel sous jacent, il faut une VM.
Il y a quelques années, MS annonçait de migrer toutes leurs applications sous .NET pour être indépendant du matériel.
Je constate que depuis que les technologies de virtualisation sont plus courantes, MS se fait plus discret sur cette migration.
Autrement pour Python, je suis d'accord, j'adore ce langage, mais il manque une certaine cohérence pour le choix d'une bibliothèque.
mais si aujourd’hui je devais concevoir une nouvelle application de plus de quelques milliers de lignes de code,
Si les gros éditeurs décidaient du jour au lendemain de basculer tout en Python/Ruby/OCAML/Lisp/Haskell/..., tu aurais exactement les outils qu'ils te manquent à l'heure actuelle qui accompagnerait ce nouveau choix "industriel"
Pour faire des applications "professionnelles" (c'est à dire développé pour une entreprise par elle même ou une société de service), il faut une taylorisation des moyens pour interchanger les développeurs entre projets. Donc il faut pouvoir tenir les développeurs par la main.
Forcément le monde du libre, c'est la liberté de faire ses propres choix, c'est moins cadré.
[^] # Re: Les deux sont bloated
Posté par darkleon (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 1.
Blague à part, 14.9MiB pour Gnotes (hors librairies partagées), Tomboy est plus gros de ~8Mib (~23Mib), ça devient vraiment du n'importe quoi pour la gestion des ressources.
Ce ne sont pas les ~200 caractères par notes qui vont aller occuper entre 15 et 20Mib de mémoire vive.
Et pourtant, quand je programme en Python ou Java, je suis le premier à laisser le GB à se débrouiller tout seul (en dehors de d'ajouter variable=null; pour faciliter son travail) à utiliser les fonctions HashMap ou Listes qui doivent bien occuper x fois plus de mémoire qu'un tableau d'octets gérée à la mimine.
Mais x doit surement être inférieur à 10 à la méga louche.
Ok, on a des Gib, mais sans vouloir optimiser en assembleur, il y a une différence entre choisir le mauvais algorithme (occupation mémoire) et un algorithme plus adapté par définition.
C'est exactement le même débat avec la vitesse, ça ne sert à rien de programmer un tri à bulle en assembleur quand un shell sort même en basic sera plus rapide sur des millions d'éléments.
Après il y a les buffers écrans, une zone 640x512 en 24bits, c'est un buffer de ~1Mib, ce buffer est pris du côté de X11 ou de l'application ? (si c'est du côté de X11, c'est pire que j'imaginais).
[^] # Re: système et garbage collector?
Posté par darkleon (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 1.
"conception par motif" (qui n'a pas d'équivalent dans un autre domaine pour son utilisation en français)
qui est plus long à dire que "Design Pattern" (qui en plus a un bonus d'attaque pipo-bimbo marketing).
Du coup, "Design Pattern" est plus adapté, plus rapide à prononcer, plus "decision manager compliant", ...
Autant "baladeur" est une traduction agréable de "walkman", "Cédérom" c'est déjà moins évident pour "CD".
J'utilise systématiquement courriel (courrier éléctronique <-> electronic mail) parce que l'idée est toujours présente et que le mot est "esthétique" à la prononciation.
Je suis à 100% pour la francisation des termes, s'ils veulent dire quelque chose.
Les anglais pourraient aussi traduire "cul de sac" (pour impasse) en "buttbag" à ce moment là :-D
[^] # Re: Question général sur les IDE
Posté par darkleon (site web personnel) . En réponse à la dépêche Sortie de Val(a)IDE 0.6. Évalué à 1.
[^] # Re: Question général sur les IDE
Posté par darkleon (site web personnel) . En réponse à la dépêche Sortie de Val(a)IDE 0.6. Évalué à 1.
Par contre, je ne comprends pas trop pourquoi tu pense que la fréquence de "rafraîchissement" est importante pour un LCD, a priori hormis pour les animations cela ne devrait pas avoir d'importance.
Tout changement d'une partie de l'écran est une animation (curseur, défilement fenêtre avec les ascenseurs,...). ça ne se limite pas aux vidéos ou jeux.
Dans le cas de suivre le curseur souris ou de suivre un texte que l'on fait défiler.
Quand le déplacement est fluide (ce qui dépend de la fréquence de rafraîchissement et aussi d'un truc bien programmé sur un processeur non asthmatique), le cerveau pré-positionne les globes oculaires par interpolations et fait une recherche locale pour trouver le curseur/mot.
Quand le déplacement est saccadé (fréquence de rafraîchissement faible et/ou truc programmé avec les pieds sur une antiquité), le cerveau pré-positionne toujours les globes oculaires par interpolation, mais comme il y a moins de valeurs, sa marge d'erreur sera plus grande, la recherche deviendra plus globale (mouvements oculaires beaucoup plus large) pour trouver le curseur/mot.
ça ne vous arrive jamais de perdre le curseur des yeux après un mouvement de souris trop rapide ?
P.S. désolé pour le double post, mais le premier n'apparaît pas sur mon ordinateur.
[^] # Re: Question général sur les IDE
Posté par darkleon (site web personnel) . En réponse à la dépêche Sortie de Val(a)IDE 0.6. Évalué à 2.
Par contre, je ne comprends pas trop pourquoi tu pense que la fréquence de "rafraîchissement" est importante pour un LCD, a priori hormis pour les animations cela ne devrait pas avoir d'importance..
Pour des questions de persistances rétiniennes comme pour le CRT, même si les pixels restent allumés, au moment du rafraîchissement, si une zone importante de l'écran change, tu verras des décalages (impressions de saccades lors d'un défilement de texte par exemple).
Tout ce qui est saccades fatigue, il faut replacer les globes oculaires sur le mot qui était visé avant le défilement et faire travailler plus activement le cerveau pour qu'il puisse repérer de nouveau ce même mot.
Si le mouvement est fluide, le cerveau positionnera les yeux par interpolation.
Donc tout changement de zone est une animation (curseur souris, défilement fenêtre) et ne se limite pas aux jeux ou vidéos.
[^] # Re: Question général sur les IDE
Posté par darkleon (site web personnel) . En réponse à la dépêche Sortie de Val(a)IDE 0.6. Évalué à 2.
Sur un CRT en mode texte, je préfère texte DEMI-BLANC (ou DEMI-VERT/AMBRE à la rigueur ) sur fond NOIR (vu que le noir, c'est moins d'électrons dans la gueule sur un CRT).
La clef de la fatigue visuelle vient de la luminosité et de la fréquence de raraichissemment qui doit être minimum 60hz sur un LCD et minimum 85hz (->100/120hz) sur un CRT (pour que l'image s'affiche plusieurs fois sur la rétine avant la fine de la persitence rétinienne).
Actuellement, je ne travaille plus que sur LCD, et je passe plus de 8h par jour devant un écran.
Ce qui est rigolo avec un CRT, c'est que sur mon amiga le 640x512@25hz faisait pleurer, quand j'utilisais un PC en VGA 640x480@60, je trouvais ça trop stable et trop reposant, et maintenant à moins de 75hz, je vois l'écran clignoter et je trouve ça trop fatiguant.
[^] # Modération : j'ai essayé la version 64bits
Posté par darkleon (site web personnel) . En réponse à la dépêche Chakra, la distribution qu'elle est bien. Évalué à 1.
L'installeur est aussi en alpha, à plusieurs étapes, l'écran bloque avant de passer à l'étape suivante. Au début, j'ai cru que ça venait de ma clef USB est à moitié pourri sur les blocs, mais la version CD me faisait les mêmes coups aux mêmes endroits.
Une petite remarque acerbe, lors de la création des points de montage, il n'est pas possible de définir plus d'un point de montage autre que les points de montages standards (/, /boot, /usr, /home, /etc, ...) et il y a un bug quand on a plusieurs disques, passer de l'un à l'autre finit par provoquer un freeze de l'installeur après un A/R
Une fois l'installation effectuée, c'est très joli et cohérent.
En plus je suis un anti-KDE (en ce moment un gnomiste par défaut), car je trouvais qu'il y avait vraiment trop de trucs installés par défaut et l'IHM KDE avec trop de réglages me convenait moins que pour gnome qui a peu de réglage et des réglages bizarres.
A vrai dire, ce qui m'a le plus impressionné, c'est que mon opteron 1,8ghz** semble avoir retrouvé une seconde jeunesse alors que ma Ubuntu 8.10 semblait ramer de plus en plus jour après jour (syndrome windosien ?).
Avant j'étais sous gentoo et fluxbox (barebone PIV@2ghz), mais j'en ai eu marre de passer plus de temps à paramétrer mon système que l'utiliser (et si j'enléve ce USE flag, je vais peut être gagner encore un peu de CPU), bien que cet effort me permetait d'avoir une machine réactive par rapport à une distribution binaire (qui compile les paquets avec toutes les options.
Et bien Chakra me redonne cette impression, et ce sont d'autres personnes qui font tout le boulot à ma place :-D
Par contre, la mise à jour automatique s'est vautré et le processus s'est retrouvé dans un état occupé mais sans bosser !
Il y a 4 desktop activés, mais pas de gadget pour passer de l'un à l'autre.
Bon j'avoue, je n'ai pas trop creusé, il manque encore pleins de détails, mais le socle est bon, j'attend de voir l'alpha4 ou la béta pour retenter l'aventure et virer ubuntu de mon DD.
** Je peux l'overclocker à 2,6 sans pb, mais j'ai un scythe de 953g sur le proc + carte gfx et alimentation passives. J'ai quand même du mettre un noctua 12db au cul pour créer un courrant d'air minimum dans le boitier, autrement la chaleur stagne.
Résultat des courses, le seul bruit que je perçois est la tête du disque dur quand elle gratte. Entre le confort de silence et la vitesse, j'ai vite choisi.
[^] # Re: Pour mieux comprendre la Chine
Posté par darkleon (site web personnel) . En réponse à la dépêche La République Populaire de Chine impose un logiciel de contrôle d'accès défaillant. Évalué à 3.
s/chine/france/i
s/chinois/français/i
s/parti communiste/[parti politique français eu pouvoir (par rotation)]/
Et tu as exactement la même situation dans les administrations Françaises un peu noyauté par le népotisme et le clientélisme.
Quand on lis que l'appel d'offre d'HADOPI a été lancé avant même que la loi soit présenté au parlement ! je me demande bien quel copain a eu le contrat.
[^] # Re: Autres liens
Posté par darkleon (site web personnel) . En réponse à la dépêche Le Conseil Constitutionnel français censure la loi HADOPI. Évalué à 2.
http://www.pcinpact.com/affichage/51341-dessin-conseil-const(...)
[^] # Re: Mauvaise fois avérée
Posté par darkleon (site web personnel) . En réponse à la dépêche Notre opinion sur GNU/Linux doit-elle être mise à jour ?. Évalué à 6.
Le jugement est un peu dur. On n'aime ou pas le style ubuntu, mais indubitablement cette distribution est utilisable avec zero connaissances en dehors de la manipulation de la souris et du clavier.
Pour les applications "pourris", dans 95% des utilisations, les gens n'utilisent pas les fonctionalitées qui font les différences entre un logiciel pro et un logiciel amateur.
Dans les exemples un peu extrême, je n'aurais jamais pensé utilisé MSPAINT pour faire une reproduction de Mona Lisa, et pourtant des fous sur le net le font par défi :
http://www.dailymotion.com/relevance/search/mona+lisa+mspain(...)
Donc pour le pro, ces fonctionalités plus policés lui font gagner du temps de travail, mais in fine, ce n'est pas l'outil qui compte, c'est ce qu'on en fait. Et puis Apple est justement là pour remplir cette niche.
Ce qui est marrant, c'est que je n'ai pas d'apriori contre Apple et je trouve leur design vraiment sympa, mais je ne supporte pas de travailler sur ce système parce que je le trouve trop "neuneu" dans l'ergonomie pour qu'il n'y ait pas de confusion possible dans l'esprit de l'utilisateur.
- La souris 1 bouton, obligé d'utiliser 2 mains pour avoir un menu contextuel
- Les animations qui durent ~1s (exemple d'ouverture et de fermeture de fenêtre), et ça depuis le système 6.
- Les menus coincés dans la barre d'outils du haut
et pleins de petits détails dans ce style.
Le tout me donne l'impression d'être sur un paquebot de luxe où je crie les ordres dans un tube qui sont ensuite executé par la salle de machines contrairement à un OS plus réactif ou on tient directement la barre.
Je comprend la philosophie d'Apple, mais j'aime pas être pris par la main quand je suis sur un ordinateur. En plus je trouve que tous ces délais ralentissent le flux de travail in fine.
Chacun ses goûts.
# La ligne de commande est plus user-friendly pour le 3éme age
Posté par darkleon (site web personnel) . En réponse à la dépêche Notre opinion sur GNU/Linux doit-elle être mise à jour ?. Évalué à 4.
En discutant avec mes parents, la famille et les personnes de leur générations, ils trouvent l'utilisation de l'informatique trop compliquée, car cela fait appel à beaucoup de mémorisation visuelle et une capacité à être curieux et cliquer partout dans le "clickodrome" pour trouver la fonction que l'on recherche (ils ne sont pas de la génération "zapping").
Ayant eu une formation plus "scolaire" enfants et un travail plus par le texte que l'image dans leur vie professionnelle, ils préfèrent avoir une procédure écrite sur les actions à enchainer pour faire une action.
Seulement avec les interfaces graphiques, les options changent de place d'une versions à l'autre, il y a beaucoup d'éléments visuels (la vue deviens généralement moins bonne au cours des années) et les applications peuvent s'ouvrir à différents endroits sur l'écran.
Beaucoup d'élément qui nécessite une plus grande plasticité mentale.
D'autant plus que la plupart s'y sont mis "la tête sur le billot", car c'était l'ordinateur et le courriel pour voir les photos des petits enfants ou plus de photos du tout !!
Ils ont plus de difficultés à retenir et pas vraiment de motivation pour apprendre (je ne parle pas des passionnés que l'on peut rencontrer à tout age et dans tous les domaines), ce qui les fait repartir plus ou moins à zéro à chaque utilisation (après 8 ans, mon père n'a toujours pas voulu associer le mot "touche entrée" à la touche entrée [elle est où ?], parce que ce n'est pas marqué dessus sur son clavier, et au boulot dans les années 80 il travaillait déjà sur un clavier, et ce n'est pas le seul de sa génération à NE PAS VOULOIR RETENIR, ça ne les intéresse pas, seul le contact familial les intéresse).
Finalement, faire une lettre en TeX sera plus simple pour eux s'ils ne sortent pas du modèle par défaut, certe, ce n'est plus wysiwyg, mais l'enchainement des commandes est visible, donc il n'ont pas à interpréter les réactions de l'éditeur de texte quand un style ne veut pas disparaître (ex une phrase en gras, suppression de la phrase, mais quand la personne retappe, le style gras est toujours selectionné).
De même pour toute autre activité, cela sera plus simple de lire un document papier qui explique étape par étape les commandes a effectuer.
Pas de réflexions, on applique bêtement les procédures.
Malheureusement, je n'ai pas le temps, ni l'envie d'ailleurs de me faire des scénarios de cas d'utilisation pour leur écrire ce genre de procédures.
Mais il y a un besoin réel, en dehors des personnes motivées, je n'ai rencontré personne qui soit un peu agé qui était content des IHM actuelle, et les effets 3D et toussa ça leur passe à une altitude stratosphérique au dessus de leur tête.
Pour conclure, la ligne de commande n'est pas user friendly si on ne sait pas ce que l'on fait car on doit apprendre la syntaxe.
Ecrire dans une langue étrangère, c'est dur, recopier un texte d'une langue étrangère, c'est simple.
Voilà pourquoi les discussions sur les lignes de commandes partent en Troll systèmatiques.
[^] # Re: Quid des performances de ces cartes ?
Posté par darkleon (site web personnel) . En réponse à la dépêche Levée de fonds pour OGD1. Évalué à 2.
Il n'y a peut-être plus de plantage X ou linux pour les chipsets intel, mais les bugs d'affichage sont encore présent.
J'ai acheté il y a 6 mois un ordinateur CM chipset intel gfx intégré avec dual-core, et tout marche nickel sous Ubuntu, sauf Google-earth qui pour une raison inconnue à pleins de bugs graphiques (textures vertes et mauves en rayure verticale, ordre d'affichage inverse des polygones, transparence foireuse, ....) et la dernière mise à jour n'a rien changé.
Et je ne suis pas le seul
http://forum.hardwaare.fr/hfr/OSAlternatifs/Hardware-2/chips(...)
http://forum.ubuntu-fr.org/viewtopic.php?id=264406
http://ubuntuforums.org/showthread.php?t=460079
et même sous BSD
http://forums.pcbsd.org/viewtopic.php?f=25&t=10300&p(...)
Du coup, je suis refroidi pour m'acheter une CM avec chipset intel, vu que la compatibilité ave linux assurée par les drivers libres, toussa... n'est pas "au top".
C'est pour ça que je suis super interessé par la carte OGD, car je suis quasiment certains que ce genre de bugs d'affichage sera corrigé super rapidement par un hacker du système qui ne va pas supporter longtemps ce "genre de conneries" contrairement à un support plus commercial qui va peut-être éventuellement prendre en compte le bug dans un méga cycle en V.
Même à 200€ je suis preneur, je préfère la stabilité et la revue de code. D'ailleurs j'ai une Nvidia 7600 (c'est pas une foudre de guerre) dans ma machine, et ce qui fait sa force ce sont ses drivers par rapports aux autres solution sous linux (ATI il y a quelques années, Intel récemment).
J'avoue que sans windows depuis 5 ans et n'étant pas joueur (du casual gaming de temps en temps), c'est plus facile pour moi de dire ça.
Et puis avec tous les gouvernements qui se demandent comment ils vont reprendre le contrôle du net avec des lois liberticides et la quasi obligation de prendre des solutions propriétaires, il faut absolument qu'on ait du hard libre, même décalé de 10ans (génération PII-PIII) en performances (fondamentalement depuis 1993, je fais toujours du courriel, du web, écrire une lettre administrative, coder, écouter de la musique sur mon ordi) avant de se faire totalement enfermer.
D'ailleurs je suis de près le projet NATAMI http://www.natami.net/ qui veut faire un nouvel "amiga" compatible AGA (+3D,son 16bits,...) avec des perfs équivalentes à un Pentium-MMX+Voodoo1 sur un FPGA et je me suis déjà demandé si la carte OGD ne pouvait pas être utilisé pour tester ce genre d'idée à moindre coût.
Ce genre de puissance suffit pour une usage courant, on pourra peut-être bientôt s'affranchir des constructeurs et du bagage de la compatibilité ascendante imposée par la distribution en binaire des OS et des applications.
[^] # Re: Windows est rancunier
Posté par darkleon (site web personnel) . En réponse à la dépêche Une année sans (MS) Windows : achever la conversion d'un utilisateur de Windows. Évalué à 2.
Je dirais effectivement un nouveau genre, c'est la reunion d'un veritable langage de programmation avec un shell et un framework.
Powershell n'est pas non plus le dernier truc qui fait le café.
Par exemple, la réunion d'un langage de programmation et d'un shell existe déjà pour Perl avec psh http://www.focusresearch.com/gregor/sw/psh/
psh is a Perl program which executes a read-eval loop with enough options so that general behavior reasonably similar to more traditional shells like 'sh' or 'bash' can be achieved, while still allowing arbitrary perl expressions to be evaluated.
Il me semble qu'il y a un équivalent sous python, mais une recherche rapide n'a rien donné.
Le principe n'est pas nouveau, Rexx (ARexx pour moi car j'étais amigaïste) est encore plus vieux sur ce principe, permettant même aux programmes GUI d'exposer leur fonctionalité en créant une API port Rexx, ce qui les transformait en utilitaire "shell" pour automatiser les traitements en externalisant les scripts (contrairement à la tendance actuelle d'intégrer l'édition de script dans les programmes eux-même)
Le problème de tous ces hybrides, c'est qu'il faut apprendre le langage (et surtout la librairie qui va avec), alors que les commandes unix permettent de faire une chose et une seule facilement.
Le seul interêt d'un shell est de rentrer les directives de manière interactive orientées manipulation fichier (pas de commande "open file", "close file" à ajouter dans le code)
Un shell unix avec ses outils de base, tu peux déjà faire pas mal d'opération par rapport à un cmd.exe. Que je me connecte à un linux (défaut bash), un serveur AIX (défaut ksh), HP ou SUN, BSD, Darwin, j'ai toujours le même écosytéme de commandes (il y a des pièges parfois sur des différences d'option) qui permettent de couvrir beaucoup de cas courant de manipulation simple, et certains outils comme netcat sont vraiment géniaux (par exemple pour lire un film sur un ordinateur distant sans créer de partage réseau ou copier le fichier du film au préalable).
Et si j'en crois le site de microsoft http://www.microsoft.com/windowsserver2003/technologies/mana(...) , powershell est installé par défaut uniquement à partir de la version server 2008 (même si on pouvait la télécharger et l'installer à partir de XP).
Mieux vaut tard que jamais, mais on ne peut pas espérer se connecter sur une machine windows hors server 2008 et être sûr d'avoir un powershell à sa disposition.
Dans quelques années, la question ne se posera peut être plus, mais pour l'instant, ce n'est qu'une option.
Ce qui n'enléve rien aux possibilités de powershell et que c'est un bon de géant en avant pour les administrateurs windows par rapport à cmd.exe
Le but recherché entre shell et powershell n'est pas le même.
[^] # Re: Windows est rancunier
Posté par darkleon (site web personnel) . En réponse à la dépêche Une année sans (MS) Windows : achever la conversion d'un utilisateur de Windows. Évalué à 1.
Le jour ou on trouvera en standard grep, awk, sed, md5sum, sha1sum, wget, wput, wc, mail, sendmail, bzip2, less, more, gzip, lzma, tar, cut, tail, head, su, sudo, at, find, zip, bc, base64, netcat, diff, patch, ln, mkfifo, cat, ssh, scp, sftp, gpg, uniq et xargs, on en reparlera, d'accord ?
Il y a boire et à manger dans cette liste, tu mélange pêle mêle, manipulation de fichiers, outils de compressions, et outils réseaux.
ça dépend de l'usage de chacun, faut pas déconner (et je suis 100% linux chez moi). Il y en a marre de se payer des outils antediluvien sous pretexte qu'ils sont "essentiels" alors que la vraie raison, c'est que des générations d'admin ont fait des scripts illisibles avec.
En plus un bash, c'est plus d'un méga en mémoire au lancement, quand on voit la faune des scripts de démarrage sous linux, et que ce mécanisme a très peu évolué, on peut se poser des questions sur les non-performances entrainées au boot.
Un système écrit sur un langage plus évolué avec une seule VMbytecode serait plus light en ressources et plus rapide.
xargs est une vaste blague, c'est une commande qui a été crée après coup pour pouvoir récupérer les argument à travers un pipe, et comme elle n'a jamais évoluée, quand tu as un espace dans tes noms de fichiers (maintenant j'utilise des espaces dans mes noms de fichiers), ça te fait planter ton beau one-liner.
Au boulot, j'utilise cygwin pour avoir des commandes unix, et comme en général, c'est pour analyser des logs, ou trouver des méthodes, mon outil numéro est "grep" (plus rapide que "rechercher" windows).
Autant j'apprécie le fait d'avoir ces commandes pour rapidement filtrer des fichiers pour trouver le problème à la main qui m'intéresse, autant si je devais automatiser une chaîne de traitement, je ne la ferais pas en sh/csh/ksh/bash (je dis ça parce que tu cites AWK, et tu ne crée pas un filtre AWK pour le plaisir par exemple)
Avec ces outils, tu te retrouves avec trop de problèmes avec les séparateurs (espace tabulation) pour faire des solutions robuste.
Si ce que je dis était faux, PERL n'aurait pas eu autant de succès, car il comble beaucoup de manque de la programmation shell où ce n'est pas intuitif (arithmétique, somme des lignes de plusieurs fichiers par exemples, collections/tableaux, ...)
Les commande unix de BASE (au sens unix d'une commande qui ne fait qu'une seule chose mais qui la fait bien), mangez en, autant il ne faut pas s'arcbouter religieusement dessus.
Maintenant la ligne de commande "dos", c'est pire, maintenant je ne connais pas le powershell.
P.S. dd est effectivement une commande essentielle de mon toolkit pour récupérer une image disk ou au contraire éclater en DUR la table des partitions rapidement.
[^] # Re: Migrer sous Linux... mais ne pas inciter.
Posté par darkleon (site web personnel) . En réponse à la dépêche Une année sans (MS) Windows : achever la conversion d'un utilisateur de Windows. Évalué à 1.