Aller au contenu

Vista bientôt remplacé?


Yozz

Messages recommandés

Invité jabial
Par exemple, mais existe-t-il des ERPs, CRMs, SCM en lisp ?

A mon avis ce serait codé bien plus vite en CL qu'en Java.

Il ne faut jamais mésestimer le pouvoir des habitudes.

A une certaine époque, tous les logiciels de compta étaient en cobol. C++ existait déjà, et tu ne nieras pas que C++ c'est mieux ; mais voilà, on faisait ça en cobol parce que c'était comme ça que les gens travaillaient.

Le paradigme objet est très intéressant lorsqu'il s'agit de représenter des choses du réel dans des applications d'entreprises.

Si on avait plus des SIs construits autour d'objets métiers tels que "client", "produit", "commande", etc… on n'aurait pas tout ce magma d'applications et de bdds aux modèles irréconciliables avec des middleware d'intégration dans tous les sens.

Mouais. Moi aussi je croyais à fond à l'objet et j'en suis un peu revenu. Les capacités objet "limitées" des langages non-objet sont à mon sens largement suffisantes pour dont on a vraiment besoin. Ceci dit, si tu veux vraiment faire de l'objet en CL, il y a CLOS.

Lien vers le commentaire
Le paradigme objet est très intéressant lorsqu'il s'agit de représenter des choses du réel dans des applications d'entreprises.

Si on avait plus des SIs construits autour d'objets métiers tels que "client", "produit", "commande", etc… on n'aurait pas tout ce magma d'applications et de bdds aux modèles irréconciliables avec des middleware d'intégration dans tous les sens.

Le problème est que scientifiquement le contenu du "paradigme objet" est très faible et dur à cerner (juste un bouquin sur les objets à délégation d'Abadi et Cardelli), incomparable avec la programmation fonctionnelle (caml, lambda calcul). C'est pas grave en soi mais ça fini toujours par se sentir à un moment à un autre (quand on veut prouver des choses par exemple). Bref l'objet ça tient plus de la self discipline en programmation (et ce n'est pas rien) que d'un paradigme de programmation.

Ocaml a une couche objet … qui ne sert quasi à rien per se (la spécialisation des objets est un truc rarissime dans la vie de tous les jours avec l'exception des systèmes de fenêtrage, j'ai aussi fait programmer des alpha-beta génériques instantiables sur différents jeux de stratégie mais franchement c'est du capillotractage). Les modules et les foncteurs (notions purements fonctionnelles) suffisent largement.

Voila c'était ma participation au Programing language flame war du jour.

Lien vers le commentaire
A mon avis ce serait codé bien plus vite en CL qu'en Java.

Il ne faut jamais mésestimer le pouvoir des habitudes.

A une certaine époque, tous les logiciels de compta étaient en cobol. C++ existait déjà, et tu ne nieras pas que C++ c'est mieux ; mais voilà, on faisait ça en cobol parce que c'était comme ça que les gens travaillaient.

Mouais. Moi aussi je croyais à fond à l'objet et j'en suis un peu revenu. Les capacités objet "limitées" des langages non-objet sont à mon sens largement suffisantes pour dont on a vraiment besoin. Ceci dit, si tu veux vraiment faire de l'objet en CL, il y a CLOS.

Faire de l'accès bdd en C++, ça a l'air bien pénible.

Note que je ne parle pas vraiment d'algorithmique mais plutôt d'un system of record au sens de l'informatique de gestion.

Et pour ça, le cobol avec ses mappings directs entre les variables et le système de stockage était très bien adapté.

La majorité de l'info de gestion, ce n'est que enregistrer ce qui se passe, et à la marge, on calcul des trucs, mais c bien à la marge.

évidemment, je ne parle pas de trucs ultra-spéciaux comme les calculs de risk management dans les salles de marché, mais plutôt d'une entreprise classique.

Lien vers le commentaire
Ce serait probablement une bonne idée, mais ça voudrait dire que tous les softs actuels s'exécuteront dans une VM. Ceci dit, vu que ça sera le cas au moment du passage au 64-bits pour le grand public, c'est vrai que les deux pourraient être groupés.

Je ne vois pas en quoi ce serait une si bonne idée : le noyau NT est un bon noyau. D'ailleurs, Mac OS X n'utilise pas un noyau BSD mais un micro-noyau Mach (largement modifié par les ingénieurs d'Apple). Les morceaux de FreeBSD qu'on retrouve dans Mac OS X sont en userland.

Lien vers le commentaire
Tssss. Teste un peu Notes 8 et tu verras. Et demande-toi aussi pourquoi MS Outlook et consorts sont quasi inexistants dans des milieux qui ont besoin de sécurité comme les banques.

c'est surtout dut à l'inertie, et que quand Notes est sorti; c'était un bon produit pour l'époque. Maintenant; beark

et je connais au moins une banque et une boite de réseau qui sont sous Outlook.

Lien vers le commentaire
c'est surtout dut à l'inertie, et que quand Notes est sorti; c'était un bon produit pour l'époque. Maintenant; beark

et je connais au moins une banque et une boite de réseau qui sont sous Outlook.

Nonon, maintenant c'est très bien aussi. Evidemment, je parle de Notes 8, pas de Notes 6.4.2 :icon_up:

C'est ca qui est drole, les gens que je connais qui critiquent Notes parlent généralement de versions antédiluviennes, comme si je critiquais Outlook 2000…

Lien vers le commentaire
Tssss. Teste un peu Notes 8 et tu verras. Et demande-toi aussi pourquoi MS Outlook et consorts sont quasi inexistants dans des milieux qui ont besoin de sécurité comme les banques.

Je connais (pour avoir pratiqué) au moins 3 ou 4 banques majeures qui ne l'utilisent pas (ou en tout cas, pas dans tous les services). Diable.

Java est à la programmation ce que Windows est aux systèmes d'exploitation. Le langage, pour un gros machin à machine virtuelle, montre un manque de puissance impressionnant.

En plus, il a ce me semble été prouvé mathématiquement la non-optimalité des machines à piles par rapport aux machines à registre.

Java, c'est un joli coup marketing de Sun. C'est youpi youpi le cobol des années 2000, avec tout ce que ça suppose de code écrit n'importe comment.

En plus, le paradigme objet est très surfait. A titre personnel je suis bien plus convaincu par caml ou common-lisp, par exemple. Dix lignes de common-lisp remplacent facilement cent de Java.

En plus Java est hyperverbeux.

En théorie, si tout le monde programmait proprement, ça ne devrait pas causer de soucis, sauf pour les drivers et autres logiciels proches de l'architecture (antivirus, défragmenteurs…). En pratique, dans la vraie vie on prend des raccourcis, on optimise, et il y en a donc partout.

En pratique, surtout, je n'ai jamais vu des projets informatiques taillés au cordeau, avec un patron ou des commerciaux réalistes, des clients ponctuels et clairs, des programmeurs top-notch et des méthodes éprouvées. Pour le moment, j'ai toujours constaté une bonne habitude du Ca Va Le Faire ou du J'VaimDébrouiller.

A une certaine époque, tous les logiciels de compta étaient en cobol. C++ existait déjà, et tu ne nieras pas que C++ c'est mieux ; mais voilà, on faisait ça en cobol parce que c'était comme ça que les gens travaillaient.

Le passif cobol est encore énorme. Et franchement, entre cobol et java, pour certaines applis, y'a pas photo : cobol remporte haut la main. Les interfaces texte, c'est tout pourri … mais c'est beaucoup beaucoup plus rapide, robuste et facile à déployer.

Mais comme c'est moins sexy, c'est appelé à disparaître au profit d'une kikoololisation de l'informatique de gestion.

Lien vers le commentaire
tu nous parles d'un produit pas encore sorti!

c'est encore pire :doigt:

Ahem.

Je connais (pour avoir pratiqué) au moins 3 ou 4 banques majeures qui ne l'utilisent pas (ou en tout cas, pas dans tous les services). Diable.

Ah ben oui, les secrétaires des banques ont moins besoin de Notes, sûr. Et puis les banques françaises… :icon_up:

Lien vers le commentaire
Invité jabial
Faire de l'accès bdd en C++, ça a l'air bien pénible.

Tu as déjà pratiqué? Moi, oui.

En Java tut le monde utilise la même lib. Ca a des avantages et des inconvénients. Mais de là à s'imaginer qu'en C++ on n'utilise pas de libs et qu'on recode tout… Faut pas déconner quand même.

Ceci dit, C++ a ses propres inconvénients que le Java n'a pas… Mais CLOS/CL n'a pas ces inconvénients, ni ceux du java :icon_up:

Note que je ne parle pas vraiment d'algorithmique mais plutôt d'un system of record au sens de l'informatique de gestion.

Et pour ça, le cobol avec ses mappings directs entre les variables et le système de stockage était très bien adapté.

La majorité de l'info de gestion, ce n'est que enregistrer ce qui se passe, et à la marge, on calcul des trucs, mais c bien à la marge.

évidemment, je ne parle pas de trucs ultra-spéciaux comme les calculs de risk management dans les salles de marché, mais plutôt d'une entreprise classique.

J'ai passé un peu de temps dans une SSII spécialisée et j'ai vu le temps que prenait le debug de code cobol. Alors bon, désolé mais ton system of record je le fais en CL et il tournera plus vite, il sera plus maintenable et plus extensible.

Je ne vois pas en quoi ce serait une si bonne idée : le noyau NT est un bon noyau.

Tu as vu le code pour dire ça? Entre le bricolage UNIVMS (ou VMSIX), le "on essaie de faire un micro-noyau mais non" et les hacks délirants dans le code, c'est cent fois plus amateur que le noyau linux.

D'ailleurs, Mac OS X n'utilise pas un noyau BSD mais un micro-noyau Mach (largement modifié par les ingénieurs d'Apple). Les morceaux de FreeBSD qu'on retrouve dans Mac OS X sont en userland.

A titre personnel, tu ne m'apprend rien.

Lien vers le commentaire
Ah ben oui, les secrétaires des banques ont moins besoin de Notes, sûr.

Que vas-tu imaginer là ? Mes sources sont autrement plus fiable que Josette, secrétaire de l'agence BNP de Chilleurs Aux Bois dans le Loiret.

On le vend à nos clients. Il est donc disponible.

T'as un job en or et des gogos pour clients. Lâche pas l'affaire !

Lien vers le commentaire
Tu as vu le code pour dire ça? Entre le bricolage UNIVMS (ou VMSIX), le "on essaie de faire un micro-noyau mais non" et les hacks délirants dans le code, c'est cent fois plus amateur que le noyau linux.

Je ne partage pas ton avis. Je pense que dans ce cas, l'analogie d'Eric Raymond est valide : NT est une cathédrale, Linux est un bazar. Donc, effectivement, Linux intègre plus rapidement certaines innovations, au pris d'un certain manque de cohérence de l'ensemble (ça part dans tous les sens : y'a quarante systèmes de fichiers différents, je ne sais combien d'extensions de sécurité, d'ordonnanceurs… pas d'ABI stable pour les drivers, etc.)

Je ne suis pas sûr qu'une approche soit nécessairement supérieure à l'autre, d'ailleurs. Et pour être honnête, j'ai tenu quelques heures sous Vista avant d'installer Ubuntu :icon_up: Mais les problèmes viennent surtout de la couche de saloperie qu'il y a au-dessus que du noyau lui-même, à mon avis (qui, je le maintiens, est bien conçu et quoi qu'on en dise, depuis XP SP2 et Vista, satisfaisant d'un point de vue sécurité).

Les développeurs BSD, en revanche, développent de façon un peu plus "carrée". Je pense que ce sont surtout les développeurs "GNU" qui aiment bien ce bordel ambiant. Je travaille quotidiennement avec les cross-toolchains GNU et c'est vrai que c'est configurable à souhait mais au bout d'un moment, quand on passe son temps à bidouiller des scripts de linkers et des makefiles, à intégrer le patchwork de bibliothèques, à corriger des RTOS libres un peu buggés, à contourner les bugs de gcc, les "incertitudes" de gdb… ben on regrette quand même un peu les bon gros IDE propriétaires qui coûtent des milliers d'euros :doigt:

Lien vers le commentaire
Invité jabial
Je ne partage pas ton avis. Je pense que dans ce cas, l'analogie d'Eric Raymond est valide : NT est une cathédrale, Linux est un bazar.

Si Linux est effectivement un bazar, NT n'est pas une cathédrale. BSD est une cathédrale. NT est une cité construite par des entrepreneurs véreux et arpentée par des voyous.

Donc, effectivement, Linux intègre plus rapidement certaines innovations, au pris d'un certain manque de cohérence de l'ensemble (ça part dans tous les sens : y'a quarante systèmes de fichiers différents, je ne sais combien d'extensions de sécurité, d'ordonnanceurs… pas d'ABI stable pour les drivers, etc.)

Tu exagères vachement. Il y a un système de fichier utilisé par 99% des gens, les extensions de sécurité c'est pareil il n'y en a qu'une ou deux qui est utilisée de façon non anecdotique, et le reste est à l'avenant. Coder un driver linux est plus simple et plus rapide que de coder un driver windows.

Je ne suis pas sûr qu'une approche soit nécessairement supérieure à l'autre, d'ailleurs. Et pour être honnête, j'ai tenu quelques heures sous Vista avant d'installer Ubuntu :icon_up: Mais les problèmes viennent surtout de la couche de saloperie qu'il y a au-dessus que du noyau lui-même, à mon avis (qui, je le maintiens, est bien conçu et quoi qu'on en dise, depuis XP SP2 et Vista, satisfaisant d'un point de vue sécurité).

Tu serais surpris de savoir tout ce qui est dans le noyau windows… probablement une bonne partie de ce que tu penses être "au dessus". Il y a encore des vrais morceaux de code win2k qui traînent sur le net, va voir par toi-même.

Je travaille quotidiennement avec les cross-toolchains GNU et c'est vrai que c'est configurable à souhait mais au bout d'un moment, quand on passe son temps à bidouiller des scripts de linkers et des makefiles, à intégrer le patchwork de bibliothèques, à corriger des RTOS libres un peu buggés, à contourner les bugs de gcc, les "incertitudes" de gdb… ben on regrette quand même un peu les bon gros IDE propriétaires qui coûtent des milliers d'euros :doigt:

Tu as trouvé plus de bugs dans gcc que dans VC++? Pas moi. Aux dernières nouvelles, le C++ géré par VC++ n'était toujours par conforme à la norme. Tu me diras que gcc non plus, mais for all practical purposes, si.

Lien vers le commentaire
Si Linux est effectivement un bazar, NT n'est pas une cathédrale. BSD est une cathédrale. NT est une cité construite par des entrepreneurs véreux et arpentée par des voyous.

Ton analogie a le mérite d'être amusante :icon_up:

Tu exagères vachement. Il y a un système de fichier utilisé par 99% des gens, les extensions de sécurité c'est pareil il n'y en a qu'une ou deux qui est utilisée de façon non anecdotique, et le reste est à l'avenant. Coder un driver linux est plus simple et plus rapide que de coder un driver windows.

De là où je suis (dans l'embarqué), j'ai sans doute une vision différente de Linux. Je vois un certain nombre de vendeurs genre Wind River ou LynuxWorks qui vendent du Linux mais, comme Linux n'est pas conçu pour répondre à des contraintes temps réel ou embarqué, ils recodent les principaux sous-systèmes du kernel à leur sauce (ordonnanceur, VM, etc.) J'ai plus l'impression qu'ils vendent la marque Linux et l'API POSIX-like que le système lui-même.

En ce qui concerne les drivers, c'est plus simple sous Linux puisque rien n'est vraiment imposé (il y a plus d'abstractions formellement spécifiées sous NT). Vu que je n'ai pas pratiqué, je ne sais pas quelle approche est la meilleure (en revanche, j'ai codé un driver sous Windows CE -- qui n'a à priori rien à voir en terme d'archi avec NT -- et j'ai apprécié le framework offert qui permet d'éviter de faire des conneries et de ré-inventer la roue).

Tu serais surpris de savoir tout ce qui est dans le noyau windows… probablement une bonne partie de ce que tu penses être "au dessus". Il y a encore des vrais morceaux de code win2k qui traînent sur le net, va voir par toi-même.

J'avais jeté un rapide coup d'oeil à l'époque où les sources ont été leakées. C'est un kernel hybride donc, oui, il y a des trucs qui ne devraient sans doute pas se trouver en kernel-land. D'un autre côté, sous Linux y'a une bonne partie du serveur X qui fait la même chose.

Tu as trouvé plus de bugs dans gcc que dans VC++? Pas moi. Aux dernières nouvelles, le C++ géré par VC++ n'était toujours par conforme à la norme. Tu me diras que gcc non plus, mais for all practical purposes, si.

J'ai trouvé quelques bugs dans la génération de code des ports de gcc pour architectures exotiques. gcc c'est bien pour Linux/x86. D'ailleurs, les développeurs d'OpenBSD essaient de s'en débarrasser tellement ça les gonfle. Quant à C++, même si c'est un "meilleur C", j'évite d'y toucher. Quelqu'un disait : "la syntaxe, c'est le Vietnam des langages de programmation" ; je pense qu'il parlait du C++ ! Personne n'arrivera jamais à implémenter un compilo C++ à la norme vu l'abomination que c'est. Cela dit, c'est vrai que Microsoft n'est pas très à cheval sur les standards dont ils ne cherchent sans doute pas à atteindre la normalisation. Je crois qu'ils ont laissé tomber le C (ils ne supportent pas le C99 par exemple) et feront sans doute de même avec le C++.

Lien vers le commentaire
Désolé ; mais dans la catégorie "Science et technologie" c'est un peu toléré, non ? :icon_up:

N'aie pas honte, tu es jeune et encore pimpant, l'avenir t'appartient, cesse de me présenter ce smiley rongé par le désespoir.

Be free little geek !

Lien vers le commentaire
Invité jabial

Ne sois pas intimidé Herbert, on est chez nous dans ce forum :doigt:

Bon, on lance une flame vim vs emacs? :icon_up:

Pour en revenir au fond, si j'avais compris que tu parlais du monde de l'embarqué je t'aurais répondu dès le début que :

- windows embarqué est vachement mieux foutu que windows tout court parce qu'ils n'ont pas eu de compatibilité ascendante à préserver à tout prix

- linux embarqué ça n'est pas mur, point barre, donc on en reparlera quand ce sera le cas - ceci dit, ça a quand même tendance à tourner plus vite et à moins planter quand même…

Concernant gcc, comme tout LL plus la plateforme cible est pratiquée et plus ça marchera bien. Ceci dit rien ne t'empêche de corriger les bugs :mrgreen:

Lien vers le commentaire
Bon, on lance une flame vim vs emacs? :icon_up:

Flame war qui n'a pas d'intérêt car avec emacs -nw tu peux te passer de vim qui n'est qu'une survivance du passé paléontologique de l'informatique. :doigt:

Tiens vim ça me fait penser à ça :

vivarij-proteus.jpg

un truc qu'on ne trouve que dans le vivarium proteus dans les grottes de Postojna, une survivance du passé qui n'a plus de raison d'être (ne serait ce la sacro sainte diversité biologique).

Lien vers le commentaire

@jabial : Rhaaa, Lisp… :icon_up: (Et CLOS est à la connaissance le seul langage respectant intégralement le paradigme de la programmation orientée objet)

Par exemple, mais existe-t-il des ERPs, CRMs, SCM en lisp ?

Je crois me souvenir que récemment nous avons eu un SCM en slip.

Lien vers le commentaire
Flame war qui n'a pas d'intérêt car avec emacs -nw tu peux te passer de vim qui n'est qu'une survivance du passé paléontologique de l'informatique. :icon_up:

Oui, et également faire envoyer des emails, éditer wikipedia, faire griller ton pain et t'entrainer à jouer Brahms.

Pour ceux qui veulent un éditeur text, il y a vim.

Lien vers le commentaire
Oui, et également faire envoyer des emails, éditer wikipedia, faire griller ton pain et t'entrainer à jouer Brahms.

Pour ceux qui veulent un éditeur text, il y a vim.

Dans la série "moquons nous des utilisateurs d'emacs et de leurs habitudes" (je dis ça mais je n'utilise pas vim pour autant, hein : je suis agnostique d'éditeur), savez-vous comment rms surfe sur le web ?

Réponse ici, c'est véridique puisque c'est lui qui le dit, et ça vaut son pesant de cacahuètes : http://www.mail-archive.com/misc%40openbsd.org/msg53860.html

(vous pouvez aussi lire le reste du thread ; c'est le troll de l'année entre rms et les développeurs d'OpenBSD, au cas où vous auriez raté ça)

Lien vers le commentaire
Dans la série "moquons nous des utilisateurs d'emacs et de leurs habitudes" (je dis ça mais je n'utilise pas vim pour autant, hein : je suis agnostique d'éditeur), savez-vous comment rms surfe sur le web ?

Réponse ici, c'est véridique puisque c'est lui qui le dit, et ça vaut son pesant de cacahuètes : http://www.mail-archive.com/misc%40openbsd.org/msg53860.html

(vous pouvez aussi lire le reste du thread ; c'est le troll de l'année entre rms et les développeurs d'OpenBSD, au cas où vous auriez raté ça)

C'est nous insulter que de croire qu'on ait pu rater ça : https://www.liberaux.org/index.php?showtopic=34973

:icon_up:

Lien vers le commentaire
Je ne vois pas en quoi ce serait une si bonne idée : le noyau NT est un bon noyau. D'ailleurs, Mac OS X n'utilise pas un noyau BSD mais un micro-noyau Mach (largement modifié par les ingénieurs d'Apple). Les morceaux de FreeBSD qu'on retrouve dans Mac OS X sont en userland.

FAUX

Ils ont porté le noyau FreeBSD sur un micro-noyau, mais c'est bien le noyau de FreeBSD. Le micro noyau comme son nom l'indique ne fait pas grand-chose (et il est libre aussi).

- linux embarqué ça n'est pas mur, point barre, donc on en reparlera quand ce sera le cas - ceci dit, ça a quand même tendance à tourner plus vite et à moins planter quand même…

Je suppose que tu parle des interfaces graphiques, parce que le nombre de matos embarqué qui tourne sous Linux ne se compte plus.

Sinon, le Lisp c'est de la branlette d'universitaire :icon_up:

(Et CLOS est à la connaissance le seul langage respectant intégralement le paradigme de la programmation orientée objet)

Ruby, le seul langage ou même un "if" est un objet. Et il a introduit des pratiques objet bien meilleures que ce qu'on peut voir utilisé avec Java par exemple (le type d'un objet n'est pas important, c'est ses méthodes disponibles).

Et c'est un langage utilisé par des vrais gens, en plus.

Pas plus tard qu'hier, un représentant de big blue me ventait les mérites de Lotus Notes 8.

Le Vaporware il y a pas que MSFT qui en fait: tiens d'ailleurs en quatre lettre:

HURD

:doigt:

HURD tourne mais sur très peu de matériels parce que personne n'a d'intérêt à en faire ; et la plupart des bonnes idées ont été portées sur *BSD/Linux. Bref "vaporware" c'est quand même dur pour un noyau dont le code source est disponible et qui a une branche Debian !

Pour revenir au sujet, la phrase que j'entends le plus autour de moi en ce moment c'est "putain de Vista". Pauvres gens qui se sentent obligés d'upgrader…

Lien vers le commentaire

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...