Popularité des éditeurs de texte sur liborg

[pankkake]

Argh, CORBA et les bus inter-objets.

C'était tellement pénible en cours (en TP en fait), que les étudiants passaient par la solution vite et sale : une socket tcp/ip classique. Et ils réinventaient leur protocole binaire par dessus. De l'arrachage de cheveux à noter et à expliquer qu'une solution pas propre pour remplacer une solution pénible, ce n'est pas une solution. (Et *paf* 4/20).

C'est parce qu'à l'époque il n'existait pas https://en.wikipedia.org/wiki/Protocol_Buffers

[neuneu2k]

Après, sur le principe, Bonobo & Co était pas forcément mauvais (et son alter-ego DCOP): vouloir offrir des interfaces accessibles (et parfois auto-descriptives) était un grand pas en avant par rapport à l'ancienne philosophie qui consistait à écrire des bouts de code en C.

Vouloir offrir des points d'acces plus souples que de linker son bout de code avec le bout de code de l'autre, oui, c'était louable, le probleme c'est qu'ils ont voulu faire une interface fortement typée, orientée objet et tout le tintouin et reproduire l'enfer des RPC.

La philosophie unix originelle de "tout est un fichier" était un petit peu limitante mais propre (encore que, avec un filesystem virtuel decrivant les ressources… comme dans plan 9, j'ai des doutes sur le coté limitant), mais passer de ça a l'enfer du RPC orienté objet, qu'il soit CORBA ou autre, c'était une erreur fatale.

Au final, presque 20 ans après toutes ces conneries, il reste HTTP pour faire des vrais systèmes distribués scalables (un machin a 4 verbes qui manipule des ressources plates avec un type mime, autrement dit un truc qui ressemble vachement a un système de fichier) d'un coté, et de l'autre des petits bouts de restes du champ de bataille de l'objet, sachant que même microsoft est loin d’être monolithique sur ce point, et qu'en interne, ceux qui disent que le web est l'exemple a suivre en terme d'architecture parce qu'ils ont lu la thèse de fielding au lieu de juste faire du PHP ont tendance a gagner du terrain massivement sur la vielle garde "DNA" dont PowerShell n'est q'une des dernières bordées.

Le plus gros problème de Microsoft en fait, c'est sa communauté, les "corp" sont bien plus ouverts et critiques que les fanboys. (c'est peut être vrai chez apple aussi remarque, mais on coupe la langue de tous les internes et on les enferme dans des boites pour qu'ils ne parlent jamais a l'exterieur).

[pankkake]

HTTP est utilisé par les gens qui ne savent pas qu'autre chose existe c'est tout

[Rincevent]

Est-ce que tu as utilisé Logo, à l'école (la petite tortue et tout ça ?) .

Depuis que j'ai appris que Logo était un Lisp undercover, hein…

[Greg42]

Depuis que j'ai appris que Logo était un Lisp undercover, hein…

Un lisp sans parenthèses ca ne peut qu'être bien :-p

[Noob]

Donc ça ne s'appelle plus Lisp mais Li (vu que le "Saturé de Parenthèse" n'est plus pertinent)

[Rincevent]

Un lisp sans parenthèses ca ne peut qu'être bien :-p

Non. Sans parenthèses, on s'y perd. La seule possibilité tolérable, c'est un système de sucre syntactique, du genre fermer toutes les parenthèses d'un coup", ou, à la Python, "fermer toutes les parenthèses jusqu'à rencontrer celle qui lui correspond sur la même colonne". Et encore. Les parenthèses sans fin, c'est un mal pour un bien (la clarté de l'arbre syntaxique sous tes yeux).

[neuneu2k]

HTTP est utilisé par les gens qui ne savent pas qu'autre chose existe c'est tout

Non, en général, il est utilisé pour tout et n'importe quoi, et quand il est utilisé correctement, ça fait le seul système distribué cross-organisationnel qui marche, voir le seul système distribué qui marche tout court…

Et quand il est utilisé incorrectement que ça soit avec des sessions partout et/ou pour faire de la RPC, c'est pas pire qu'autre chose et c'est quand meme relativement facile a integrer worse is better.

HTTP, c'est la vielle philosophie unix mais pour les réseaux, il faut juste le voir, c'est ce que 9P cherche a etre depuis 1992, mais en prod

[WBell]

Non. Sans parenthèses, on s'y perd. La seule possibilité tolérable, c'est un système de sucre syntactique, du genre fermer toutes les parenthèses d'un coup", ou, à la Python, "fermer toutes les parenthèses jusqu'à rencontrer celle qui lui correspond sur la même colonne". Et encore. Les parenthèses sans fin, c'est un mal pour un bien (la clarté de l'arbre syntaxique sous tes yeux).

C'est pas Apple qui avait tenté le coup avec Dylan, le LISP avec une syntaxe Algol (pour ramasser les dev C/C++ puis Java) ?

[Rincevent]

C'est pas Apple qui avait tenté le coup avec Dylan, le LISP avec une syntaxe Algol (pour ramasser les dev C/C++ puis Java) ?

Je ne sais pas trop… Mais peut-on réellement qualifier de LISP un langage fonctionnel sans S-expressions ?

[h16]

LISP, un langage.

Allons.

[Malky]

LISP, un langage.

Allons.

On peut écrire "Hello World!" avec, donc a priori c'est un langage

[Malky]

La philosophie unix originelle de "tout est un fichier" était un petit peu limitante mais propre (encore que, avec un filesystem virtuel decrivant les ressources… comme dans plan 9, j'ai des doutes sur le coté limitant), mais passer de ça a l'enfer du RPC orienté objet, qu'il soit CORBA ou autre, c'était une erreur fatale.

Limitante dans son implémentation, pas dans l'absolu. Le gros avantage étant la cohérence, comme pour http d'ailleurs.

[pankkake]

Plan9 est assez intéressant, mais finalement pas mal d'idées se retrouvent sous Linux, avec /sys, /proc, unionfs, FUSE…

Manque /net mais je me demande quel genre de performances ça impliquerait.

[Malky]

Manque /net mais je me demande quel genre de performances ça impliquerait.

http://en.wikipedia.org/wiki/Network_File_System

[pankkake]

Non, ce n'est pas du tout la même idée, il s'agit de gérer le réseau (donc TCP et compagnie) comme s'ils étaient des fichiers.

Au passage, s'il y a bien un truc qui est un gros caca, c'est NFS (quoique je n'ai pas essayé la v4, ça a l'air beaucoup mieux)

[Malky]

Ah cette partie là… FUSE permet de le faire, à priori. Je ne connais pas d'implémentation existante pour le moment cela dit.

NFS est lourd à configurer, mais SMB est bien plus caca amha. Le(s) créateur(s) mérite(nt) amplement la peine de mort.

[pankkake]

Ouais avec FUSE et TUN/TAP on pourrait faire une démo.

Si j'avais la motivation je le coderai

Oui au moins NFS, c'est spécifié correctement mais comme NFS, il y a eu des évolutions, peut-être plus radicales.

[neuneu2k]

Limitante dans son implémentation, pas dans l'absolu. Le gros avantage étant la cohérence, comme pour http d'ailleurs.

Voila, cohérence, orthogonalité des concepts, simplicité, ouverture (parce que la cohérence et l'orthogonalité des concepts, on l'a aussi dans WS-*… )

[Rincevent]

LISP, un langage.

Allons.

C'est tellement un langage qu'on peut faire des applications importantes, des compilateurs et même des systèmes d'exploitation avec.

Pour comparaison, Genera a été opérationnel plus de quinze ans et des gens travaillent toujours dessus ; JavaOS, lui, a été abandonné au bout de 3 ans à tourner en rond ; et Singularity, pourtant plus prometteur, a été abandonné au bout de sept ans.

[h16]

C'est tellement un langage qu'on peut faire des applications importantes, des compilateurs et même des systèmes d'exploitation avec.

Oui. Licorne 1.0 et WonderlandOS. Connu.

Et j'étais 100% sûr que tu répondrais à ma remarque.

[pankkake]

Singularity a toujours été un pur produit de recherche, je ne dirais pas vraiment qu'il a été abandonné.

[jubal]

Non, ce n'est pas du tout la même idée, il s'agit de gérer le réseau (donc TCP et compagnie) comme s'ils étaient des fichiers.

Avec bash il y a /dev/tcp, mais c'est juste pour des connections TCP. Pour le reste il y a netcat et socat (mais c'est pas des fichiers ok).

Tient je viens de me demander quel était l’équivalent de socat en powershell .

[pankkake]

Avec bash ?

edit: ah oui http://www.linuxjournal.com/content/more-using-bashs-built-devtcp-file-tcpip

vraiment bizarre de rendre ça interne à bash

Tient je viens de me demander quel était l’équivalent de socat en powershell .

socat.exe

http://blog.gentilkiwi.com/programmes/socat#englishversion

[jubal]

socat.exe

http://blog.gentilki...#englishversion

C'est pour cygwin.

D'ailleurs pour des tools command line windows je me demande si cygwin n'est pas une meilleurs solution que powershell.

On peut utiliser les binaire cygwin depuis powershell, mais du coup autant utiliser bash.

[pankkake]

Ben powershell est capable d'utiliser un exécutable normal, quand même ?

mais du coup autant utiliser bash

oui effectivement

[Rincevent]

Et j'étais 100% sûr que tu répondrais à ma remarque.

Successful troll is successful.

[Poil à gratter]

JavaOS, lui, a été abandonné au bout de 3 ans à tourner en rond.

J'avais essayé Jnode qui avait pris le relai de JavaOS en quelque sorte, mais le projet semble abandonné:

http://www.jnode.org/

Sinon il y a aussi JOS, mais dernière mise à jour date de plus de 2 ans:

http://sourceforge.net/projects/jos/

Enfin bon, j'ai toujours vu ça plus comme des Proof of Concept que des vrais OS.

Au final, presque 20 ans après toutes ces conneries, il reste HTTP pour faire des vrais systèmes distribués scalables (un machin a 4 verbes qui manipule des ressources plates avec un type mime, autrement dit un truc qui ressemble vachement a un système de fichier) d'un coté, et de l'autre des petits bouts de restes du champ de bataille de l'objet, sachant que même microsoft est loin d’être monolithique sur ce point, et qu'en interne, ceux qui disent que le web est l'exemple a suivre en terme d'architecture parce qu'ils ont lu la thèse de fielding au lieu de juste faire du PHP ont tendance a gagner du terrain massivement sur la vielle garde "DNA" dont PowerShell n'est q'une des dernières bordées.

Oui REST fonctionne bien tant qu'on a des besoins qui collent au paradigme totalement stateless du machin. Mais bon, dès qu'on a besoin d'avoir un état conversationnel, bin on en revient à ces bon vieux objets, avec un système de message au milieu.

Enfin bon, tout le monde est très excité avec REST, les nouveaux frameworks MVC Javascript, et puis des jouets comme Node.js. Et puis l'excitation retombera une fois que les problèmes apparaîtront au grand jour, mais finalement les architectures objets seront toujours là pour faire le gros du boulot

Passé ce stade je vois que ce n'est même pas la peine de discuter, les fanboys de Microsoft ça existe maintenant, et je ne suis pas psychologue.

C'est bien un langage de script, bash aussi, mais bash est une bonne interface homme-machine et un langage de script limité, PowerShell est l'inverse, ce qui n'est pas un problème tant qu'on sait de quoi on parle et pourquoi on l'utilise. Et un shell, c'est bien une interface homme-machine. Et des langages de script interactif il y en a déjà des dizaines et ils ont plus de 10 ans.

Bref, il s'agit tout simplement d'être au fait de la réalité. Trop duuuur.

Ha oui là c'est tout de suite vachement plus clair…. ou pas.

[neuneu2k]

Oui REST fonctionne bien tant qu'on a des besoins qui collent au paradigme totalement stateless du machin. Mais bon, dès qu'on a besoin d'avoir un état conversationnel, bin on en revient à ces bon vieux objets, avec un système de message au milieu.

Il n'y a aucun souci a avoir un état conversationnel dans une architecture REST, c'est juste une question de créer une ressource pour la conversation, c'est meme le seul moyen de faire quelque chose de réellement stateful a grande échelle, et de fait, ça date d'il y a bien plus longtemps que REST, tout ce qui est conversationnel et important, ça a un "n° de dossier" qu'on peut réutiliser avec un autre interlocuteur, voir meme entre deux interlocuteurs différents des originaux, pour continuer la conversation.

Les modeles statefull classiques ne sont pas assez souples pour gerer de la distribution dans le temps et l'espace, le premier qui colle un moniteur transactionnel a la place de SWIFT parce que "comme ça, on n'a pas a gérer a la main les problèmes de transactions incomplètes on a une garantie de complétude ou de rollback" tue l'économie mondiale en quelques heures, c'est pire qu'une bombe atomique.

Ca ne change pas le fait que derriere, les machins qui gerent les ressources sont codées avec un paradigme objet et/ou fonctionnel, REST est un modele de modelisation des systemes distribués, pas un modele de programmation, et n'a strictement aucun rapport avec Node.js

Ensuite, moi aussi ça me manque un système de notifs, c'est connu, ce qui manque a REST, c'est l'abonnement a des notifications sur update d'une représentation de ressource, mais c'est non trivial a large échelle (ce n'est pas comme si on savais le faire a relativement faible latence, sans dépenser une fortune dans des solutions ad-hoc en contraignant massivement le format de la représentation, comme les distributeurs de données de marché).

Non, il ne suffit pas de mettre une applianceau milieu d'internet, ça marche pas

[Malky]

REST est un modele de modelisation des systemes distribués

Hmm on se rapproche du rapport sur les rapports concernant l'édition de rapports sur les rapports, là… ou bien ?