Golum va nous manquer, mais on fera sans :(
C'est une lapalissade de dire que l'on cherche à créer des langages permettant de disposer de plus d'expressivité afin d'améliorer la productivité.
Des langages comme Ruby, caml, perl, python, etc... sont à la mode, permettent d'aller plus loin, de diminuer la taille du code, en sacrifiant parfois à la lisibilité.
Il me semble depuis quelques mois que mes réflexion avancent sur ce sujet, que la clé d'une (r)évolution réelle des langages de programmation nécessite la mise au point d'un langage déclaratifs (axiomatiques) turing complet.
Les expression régulières, le langage Xpath, le Sql, etc... sont des langages axiomatiques, déclaratifs sans être turing complet, et c'est bien normal car leur objectif est d'être spécialisé, ce qui permet leur existence.
En effet, passer du paradigme régnant aujourd'hui en maître dans les paradigmes de langages - consistant à décrire à l'ordinateur les étapes successives de traitement permettant d'aboutir à un résultat - à des paradigmes dans lequel on décrit quelques règles de manières déclaratives en demandant à la machine d'inférer, est une étape difficile, peu explorée en réalité, et posant plein de problèmes théoriques.
Adoptons une démarche incrémentale.
Les langages actuels, langages fonctionnels y compris, se contentent de décrire un graphe orienté, décrivant le parcourt d'un automate virtuel.
Que l'on ajoute tous le sucre syntaxique que l'on veut, que l'on permette de mettre des fonctions en paramètres d'autres fonctions, on est toujours rappelé par cette réalité.
L'objectif des librairies, de la programmation fonctionnelle, objet, est souvent de cacher localement cette réalité, en rendant déclaratif certains traitements.
Certains langages, parce que dynamiques ou bien compilé, sont grâce à leur sémantique interne capables d'implémenter des traitement déclaratif de haut niveau.
Les langages fonctionnels, ou objets implantant une sorte de type Block (ie. correspondant à une liste d'instructions) permettent en effet de définir des fonctions exécutant un code donné en argument dans certains cas, de procéder à des opérations ensemblistes sur des tableaux avec des fonctions de comparaisons données par les utilisateurs.
En particulier, on peut y implémenter les opérations de bases chères au utilisateurs de langages fonctionnels, comme map, fold et filter : http://www.cse.unsw.edu.au/~en1000/haskell/hof.html [1]
Ces fonctions restent assez abordables et sont d'une puissance fabuleuse.
Je rappel une problématique qui me semble clé :
Un langage plus expressif, plus puissant, doit l'être tout en restant le plus abordable possible, avec l'approche qui a prévalu lors de la création d'un langage comme LOGO ou AppleScript : permettre à des non informaticiens un minimum logique d'écrire au moins de petits programmes.
Si on oublie cette problématique, alors la question est réglée : il faut jeter Java/C#/C++, et former tout le monde d'urgence à Haskell/Caml/Lisp/Oz.
Malheureusement, peu de développeurs ont le niveau théorique leur permettant de maîtriser un tel langage.
Je me souviens que la plupart de mes collègues de BTS ne maîtrisaient pas vraiment le concept de fonction d'un point de vue théorique (produit cartésien, tout ça), mes collègues de boulot pareil (la fameuse réponse "un langage fonctionnel ? C'est un langage qui marche ?").
Et même des gens très qualifiés peu habitué à cette logique ne la trouve pas aisée à prime abord.
Un exemple récent est cet échange http://linuxfr.org/comments/834613.html#834613 [2] dont tout habitué de LinuxFR reconnaîtra des interlocuteurs très compétents.
Bref, je pense que la formation n'est pas l'unique problème de la marginalité des langages fonctionnels, même si elle reste importante.
Plusieurs voies d'évolution:
Le déclaratif sur les données
La plupart du temps, les données sur lesquels on travaille ont une forme d'arbre, on est donc en terrain connu, et des formalismes comme Object Query language (ou tout autre query language conçu pour Xml) par exemple, permettent de rendre déclaratives des opérations qui en ont bien besoin.
En effet, d'après http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/doc(...) [3] , 90 % des entiers du code source du jeu Unreal sont dédiés à parcourir des tableaux. C'est certes un exemple spécifique de par la part prépondérante de concepts issus d'algèbre linéaire dans ce genre de logiciel, mais pour des logiciels de gestion, on en est sûrement pas très loin, en tout cas en ce qui me concerne.
Disposer d'un SQL objet built in le langage permet d'accéder beaucoup plus vite à l'intuition du développeur, gage de réduction d'erreurs, de productivité, comme l'expliquait Victoria Livschitz dans une interview (traduction française aproximative ici : http://linuxfr.org/~Montaigne/19629.html [4] ).
En effet, on se retrouve ici avec un problème de (sucre) syntaxe(ique) : même si l'on peut implémenter des fonctions sur listes permettant de réaliser des intersections, unions, différence avec en argument la fonction de comparaison, permettant au fin du fin de recomposer à peu près proprement et à peu près déclarativement une requête SQL, ces dernières sont plus intuitives car tout simplement plus proches du langage naturel.
Par exemple pour trouver les chaîne égales, dans listStr au chaînes embarquées dans un objet Item :
Select listStr.element from listStr, listItem where listStr.element = listItem.element.link
(ici élement est le nom que l'on donne au champ d'une table avec un champ unique, un tableau de chaîne par exemple)
On peut l'écrire aussi :
liststr.intersection(listItem, {listStr.element = listItem.element.link});ou pire en java
Vector t3 = listStr.intersect_with_func(listItem,new FonctionBool() {
public boolean compare(Object el1, Object el2){ return ((String)((Item)el1).link).equals((String)el2)); } }
);La richesse dans la déclaration des structures
D'après [3], page 35 une statistique impressionnante : 40 % des for du code du moteur d'Unreal sont des compréhensions fonctionnelles, c'est à dire une liste du genre :
s = [ x | x E [0..inf] | x²>36 ];s est bien entendu une liste.
Il faut bien reconnaître que les variables déclarées classiquement dans nos langages typés (Java/C# pour citer les plus utilisés dans l'industrie) sont des stéréotypes directement issus de la machine.
Un entier est arbitrairement compris entre -2^n et 2^n
Une chaîne est une liste de caractère.
Un flottant est de même un nombre compris entre -2^n et 2^n mais avec des décimales en +, elle même cadrées.
Bref, ce n'est pas intuitif, et le programmeur est obligé de tracer les effets de bords et les répercutions de ce genre de partis pris aux racines historiques.
Il serait peut être temps de proposer des langages à vocation industrielle, d'informatique de gestion, ayant des syntaxes permettant de décrire une variable selon une structure prédéfinie, et non plus un stéréotype machine calqué sur les registres du processeur.
Que ce modèle fut valable sur des machines tournant à quelques mégahertz et quelques centaines de Ko de mémoire est parfaitement cohérent. Mais avec presque 3 Ghz et plusieurs Go, des compilateurs puissant permettant une analyse de flot (analyse de toutes les exécutions possible du code, ce genre d'algo consomme beaucoup de mémoire à la compilation), il serait peut être temps...
Après cette digression, quelques exemple :
Une chaîne avec un masque
str : \d{2}-\d{3}-\d{2}ou le contenant
str : [ String | contains \d{2}-\d{3}-\d{2} | StartWith W];Un entier appartenant à un sous ensemble de |N
i : [ x : Int | x E [0..inf] | x mod 2 = 0 | x>51];Un pattern matching à tout les étages
L'idée d'utiliser du filtrage à haut niveau se retrouve dans Caml, ou plus récemment dans TOM http://tom.loria.fr/ [5]
En caml, on peut faire du filtrage de type, ainsi que de forme de liste. A ma connaissance, on ne peut pas faire grand chose de plus, mais c'est déjà assez puissant.
TOM, dont je reprendrai ici juste des idées, permet déjà de faire des choses un peu plus sioux
(je reprend ici un slide http://sedre.loria.fr/seminaire/060203-ACL-YTo.pdf [6])
(x*,a,y*) : recherche l'élément a dans la liste
f(X1*,x,x,Y*) -> f(X*,x,Y*) : élimine des doublons.
Ca ressemble encore beaucoup à du langage mathématique, mais c'est pas mal intuitif
TOM est très intéressant, mais comme tous les trucs de la fac, ça y restera, et de toutes façons c'est quasiment imbitable.
Ce serait un langage très intéressant à recomposer afin d'en faire quelque chose d'un minimum intuitif.
On pourra aussi proposer de la manipulation d'arbre :
[
<b @Match "(i.*)"=@Match"\d+">[
@Match ".*?\d+.*?Attention.*"
]
@Match "(.*)"
]
->
[
[
<bla id="3" @Match.capt 1=@Match.capt 2>@Match.capt 3
]
]
ou
[
@match_grammar "(.*?)ELEMENT `(?[0-9]+[A-Z]?)?`{'and',',',' ',`(?[0-9]+[A-Z]?)?`}(.*?)"
]
->
[
@capt 1 @match_grammar.captur.foreach elt <ref id=@fonctionTrouveIDde(elt)>[(elt)]
];
( les `` servent à capturer
Bon ma syntaxe est pourrie (et pas intuitive ;-), mais l'idée est décrire des sortes de regexp, et de définir des règles de transformation
Le dernier exemple est un cas réel dans sa forme (complètement réécris bien sûr), et m'a posé pas mal de problèmes, à coder à la main, en java.
Le problème du pattern-matching, lorsqu'on le mélange à un paradigme classique de description d'automate virtuel, est le bordel que ça implique dans le code car cela peut rentrer en collision avec des données (la variable tmp de type string qui peut valoir toutes sorte de choses le long de l'exécution du programme).
Je ne parle même pas de la programmation orientée Aspect, cette intéressante bidouille, qui consiste à faire faire à l'automate des sauts en 4ème dimension du graphe...
Vers une grammaire à langage naturelle
Car là est peut être la clé la plus fondamentale du changement: un langage intuitif est proche du langage naturel (non, Cobol est un faux contre exemple). Mais cela nécessite peut être de dépasser les grammaires LL, LR, etc...
Ces grammaires vérifient une liste de règle basé sur le typage d'expression.
Une grammaire de langage naturelle, se base sur la nature des mots, et de celle-ci émerge une fonction. C'est le sens du mot combiné avec le graphe syntaxique qui fait émerger le sens.
Le gros problème de ces grammaires est leur potentielle ambiguïté.
J'ai rien d'autre d'intelligent à dire sur ce sujet ;-)
# pas mal !
Posté par chl (site web personnel) . Évalué à 3.
De toute facon qui va tout lire ?
[^] # Re: pas mal !
Posté par BAud (site web personnel) . Évalué à 3.
dès que j'ai le temps (ce soir donc)
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
# ambiguité
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: ambiguité
Posté par Ontologia (site web personnel) . Évalué à 4.
Le lojban http://fr.wikipedia.org/wiki/Lojban en est un exemple
Sa grammaire est conçu pour être non ambigüe, et expressible de façon unique.
Bien entendu, c'est un langage assez déroutant, qui, bien que quasiment conçu dans l'idée (entre autre) de permettre un jour le dialogue entre ordinateur et humain, reste assez difficile à apprendre, et en tout cas impossible à imposer culturellement comme base d'un langage de programmation.
On pourrait alors se tourner vers le basic english http://ogden.basic-english.org/fbasice.html qui propose une version simplifiée de l'anglais.
Il s'agirait de la simplifier, de la transformer en grammaire type pidgin et d'user obligatoirement de parenthèse afin de lever les ambigûités.
Je m'étais amusé à imaginer ce que cela pourrait donner : http://wiki.loria.fr/wiki/Lisaac/M%C3%A9talangage
Plus sérieusement, le problème est de prouver que l'on puisse extraîre une grammaire non ambigue en simplifiant une langue naturelle, c'est un problème théorique sur lequel un travail de recherche serait intéressant.
Maintenant, je n'ai parlé des langages naturels qu'en fin de texte, et ça occulte 80% du texte qui parle d'autre chose. Et c'est plus ça qui m'intéresse...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ambiguité
Posté par fmaz fmaz . Évalué à 3.
Ce que je veux dire, c'est qu'imposer les parenthèses n'est pas nécessaire. Dans pas mal de cas, ce n'est pas ambigu. En revanche, le compilo peut te dire là où il en manque, un peut comme quand le compilo d'ocaml te dit que ton patern matching n'est pas exaustif et qu'il te sort un exemple.
Blop.
[^] # Re: ambiguité
Posté par Ontologia (site web personnel) . Évalué à 2.
Il a fait des papiers là dessus ? Il s'appelle comment ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ambiguité
Posté par fmaz fmaz . Évalué à 2.
[^] # Re: ambiguité
Posté par Yusei (Mastodon) . Évalué à 3.
En gros, j'ai peur que même si on programme en lojban ou autre langage non ambigu, on se retrouve, pour exprimer clairement ce que l'on veut, à devoir écrire des tonnes de précisions.
[^] # Re: ambiguité
Posté par Dr BG . Évalué à 3.
- lexical (les mots sont dans le dico), ok
- syntaxique (les phrases sont elles bien formées), ok
- sémantique (la phrase a-t-elle un sens ?), déjà assez difficile...
- pragmatique (dans quel contexte a été énoncée la phrase ?).
Ce dernier est trop négligé par les informaticiens :-)
exemples archi-connus :
1) la petite brise la glace
2) le boucher sale la tranche
c'est bon lexicalement, syntaxiquement et sémantiquement. Il manque cependant le contexte pour comprendre ces phrases sans ambiguïté :
1) s'agit-il d'une petite fille qui casse la glace ou d'un petit vent qui la congèle ?
2) le boucher met-il du sel sur le steak ou n'est il pas propre et il la coupe ?
Bref, je ne vois pas comment un compilo pourrait comprendre le contexte :-)
[^] # Re: ambiguité
Posté par palm123 (site web personnel) . Évalué à 2.
1) la petite brise la glace
2) le boucher sale la tranche
Je connaissais juste
"la belle ferme le voile"
encore un exemple où seul le contexte permet de savoir où est le verbe dans la phrase.
ウィズコロナ
# cduce ? et les sous type ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: cduce ? et les sous type ?
Posté par Ontologia (site web personnel) . Évalué à 2.
Cduce est extrêmement intéressant, mais un peut trop universitaire, et pas assez adapté au monde de l'entreprise.
Je bosse dans un boite où on fait de l'ingé documentaire et à ce titre je travaille beaucoup sur de l'XML, mes collègues et moi avons pas mal d'expérience dans le domaine (surtout eux, ça fait qu'un an que j'y suis).
Je les vois franchement pas se former à CDuce. C'est même pas la peine que j'en parle, on va encore me regarder comme un extraterrestre, déjà que je leur fait peur avec Perl et les expressions régulières...
C'est très dommage, car on multiplierait notre productivité par 3.
Il faut donc concevoir un truc qui soit plus facilement utilisable, quitte à ce que ce soit un front-end pour cduce, le pied c'est que ça produise du bytecode Java, là je pense que Cduce aurait beaucoup de chance d'être utilisé.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: cduce ? et les sous type ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: cduce ? et les sous type ?
Posté par Ontologia (site web personnel) . Évalué à 2.
Une fois la réflexivité disponible, on pourra probablement coder ce genre de chose dans la lib, et j'y pense souvent.
C'est d'ailleurs vrai pour d'autre langage.
Le problème, c'est que ça sera toujours une chaîne de caractère en argument de fonction.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: cduce ? et les sous type ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour une telle lib, tu as besoin de la reflexivité.
Si le système de build est géré par lisaac lui-même, tu peux imaginer de la compilation paramètrique (en gros, cela revient à compiler à la volé, modulo le fait que l'on ne cherche pas du tout à être léger et que cela intervient à la compilation du projet). Donc, cela permet de faire des filtres de code comme certain module perl (je sais cela peut paraitre immonde mais cela ne se passe qu'à la compilation et c'est juste pour une lib).
Tu peux imaginer une fonction qui contient du code en "string" mais qui sera compiler elle-même, un peu comme les regex du perl.
"La première sécurité est la liberté"
[^] # Re: cduce ? et les sous type ?
Posté par pomperoi . Évalué à 2.
Ou plutôt comme eval("...code...") non ?
[^] # Re: cduce ? et les sous type ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Mais pas besoin de filtre de source pour faire ça, il "suffit" d'un bon propagateur de constante suivi d'une élimination de code mort.
Le filtre de source est plus pour se permètre d'ajouter un sucre syntaxique. C'est crade mais si lisaac contient son propre compilo, on peut imaginer utiliser le parseur de lisaac lui même avant de faire une modification.
Lisaac étant minimaliste, je ne pense pas que bidouiller sa grammaire soit super utile et propre.
"La première sécurité est la liberté"
[^] # Re: cduce ? et les sous type ?
Posté par castagna . Évalué à 2.
Est-ce qu'un graphical front-end pour CDuce tel que celui decrit dans ce papier
http://www.pps.jussieu.fr/~gc/papers/pbe.pdf
irait ?
Sinon, nous on est prenant pour des suggestions. Tu peux les poster dans users@cduce.org
No bytecode I'm afraid (pas tout de suite au moins)
---Beppe---
[^] # Re: cduce ? et les sous type ?
Posté par lasher . Évalué à 2.
[^] # Re: cduce ? et les sous type ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Par contre, l'interret est dans la somme de code qui disparait. En fait, il y a plein de classes mères virtuelles qui deviennent inutile et en plus cela retire une dépendance qui est souvent artificielle.
"La première sécurité est la liberté"
[^] # Re: cduce ? et les sous type ?
Posté par lasher . Évalué à 2.
Un article plus « simple » (même s'il reste très théorique) est « A gentle introduction to semantic subtyping » [1]. Ça reste plutôt difficile à digérer quand on n'a pas l'habitude, mais c'est extrêmement intéressant.
À noter qu'une bonne intro à ces deux articles se trouvent dans le rapport de stage de DEA d'Alain Frisch; pour les courageux, sa thèse (230 pages) explique tout, du côté « semantic subtyping » jusqu'à l'implémentation de CDuce. Là par contre, j'ai décroché assez vite.
[1] « gentle », mais bien sûr ...
# Superbe ! mai je me pose une question...
Posté par jeffcom . Évalué à 3.
- l'utilité d'avoir plusieurs langages n'est-elle pas, justement, d'adapter le code à la vocation de l'application, à son but ? (chuis peut être pas clair, j'ai la crève, soyez indulgents !)
- avoir différents langages ne permet-il pas d'approcher un problème, de "l'expliquer à la machine", de manières différentes, de manière à optimiser la vitesse d'exécution, ou optimiser la taille en mémoire, de manière à être plus simplement maintenu et répandu etc... ?
- un langage dit "naturel" ne l'est réellement que si on connaît sa grammaire et sa syntaxe. Le mandarin est très naturel pour un chinois, beaucoup moins pour un français, par contre, l'italien peut être assez naturel pour un espagnol ou un français... bref... n'est-ce pas un peu trop suggestif pour permettre d'aboutir à quelque chose de réellement utile ? Il est vrai, c'est un peu la quête du graal, mais est-ce réellement réalisable/pertinent/opportun de chercher à créer un N° langage qui se veut naturel tout en sachant qu'il ne pourras jamais autant l'être qu'on le voudrait ?
voila pour les questions, je retourne au lit avec ma bouillotte...
[^] # Re: Superbe ! mai je me pose une question...
Posté par Ontologia (site web personnel) . Évalué à 2.
- l'utilité d'avoir plusieurs langages n'est-elle pas, justement, d'adapter le code à la vocation de l'application, à son but ? (chuis peut être pas clair, j'ai la crève, soyez indulgents !)
Oui mais pour moi, c'est une bidouille organisée. Ca oblige les devs à connaître différents langage. Déjà que mon chef veut pas entendre parler de Perl parcque qu'on est que deux dans l'équipe à le connaître, j'ose pas imaginer une approche avec 5 langages différents.
C'est pour cela que je réfléchissais à un saint graal qui unifie le tout.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Superbe ! mai je me pose une question...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si il permet de remplacer les Makefile, les autotools, des générateurs de codes, c'est déjà pas mal.
Lisaac a pour lui ça syntaxe hyper simple de base. Si ensuite, il intègre de la preuve et le système de "contenaire magique", il peut faire déjà beaucoup !
"La première sécurité est la liberté"
[^] # Re: Superbe ! mai je me pose une question...
Posté par Matthieu Lemerre . Évalué à 2.
L'utilisation de certains DSL peut paraitre evident (comme cites ci-dessus: Xpath, SQL etc); ce qui l'est moins c'est l'utilisation de DSL integres au languages par exemple, des sous-langages permettant d'ecrire des parseurs comme Bison, ou des
extensions SQL a C). Peu de langages encouragent a l'utilisation systematique de DSL, a part Lisp (a ce propos, j'encourage fortement la lecture de On Lisp, de Paul Graham, disponible gratuitement sur internet).
Cette utilisation systematique permet effectivement de rendre les programmes de plus en plus declaratifs, et de permettre de faire des verifications au "compile-time".
Un exemple: un DSL precis pourrait etre les interfaces utilisees dans le noyau Linux.
Par exemple, un driver reseau utilise ceci:
static struct pci_driver ne2k_driver = {
.name = DRV_NAME,
.probe = ne2k_pci_init_one,
.remove = __devexit_p(ne2k_pci_remove_one),
.id_table = ne2k_pci_tbl,
#ifdef CONFIG_PM
.suspend = ne2k_pci_suspend,
.resume = ne2k_pci_resume,
#endif /* CONFIG_PM */
};
L'utilisation d'un DSL pour les drivers PCI du noyau resulterai en qqchose comme ceci:
pci_driver ne2k = {
name : DRV_NAME;
probe : ne2k_pci_init_one;
remove : ne2k_pci_remove_one;
id_table : ne2k_pci_tbl;
suspend : ne2k_pci_suspend;
resume : ne2k_pci_resume;
}
Ce type de DSL permettrait de gerer plus facilement les changements d'interface binaires (pas besoin de retoucher aux sources), et permet de faire des verifications a la compilation (typage par exemple).
Utiliser un tel DSL n'est pas apprendre un nouveau langage; c'est extremement simple, et plus simple que d'apprendre a utiliser une librairie par exemple.
Le langage L (http://www.nongnu.org/l-lang , attention la page est un peu outdated) est concu pour pouvoir ecrire ce type de DSL. A titre d'exemple, voici un extrait d'un parseur ecrit dans le DSL de parseur:
grammar Numeric = {
rule Digit:Character = d:[0-9] { d - Character( '0')};
rule Decimal_Number:Int = n:( d:[1-9] {d - Character( '0')})
(d:Digit {{n = n*10; n = n+d}})* {n};
rule Hexa_Digit:Character = (Digit | d:[a-f] { d - Character( 'a')});
rule Hexadecimal_Number:Int = "0x" n:{0}
(d:Hexa_Digit {{n = n*16; n = n+d}})* {n};
rule Number:Int = Decimal_Number | Hexadecimal_Number
}
Dans cet exemple, on mixe la DSL du parseur (permettant d'exprimer la grammaire) avec du code L (permettant d'exprimer des actions semantiques). Dans ce cas precis, on est en train de calculer la valeur des entiers parses tout en les parsant.
En resume, je pense que ce type de langage permet une plus grande surete, flexibilite, et facilite d'utilisation par la programmation declarative. Par contre, je ne pense pas que le langage naturel soit la cle, mais plutot d'avoir des syntaxes specifiques bien adaptees a chaque DSL.
Si vous etes interesses par ce type de langage, L est en plein developpement mais est deja fonctionnel (il dispose d'un compilateur dynamique, de DSL facilitant le developpement, et d'un translateur vers C, et une partie de L est deja ecrite en L);
un exemple de projet serait l'ecriture d'un DSL pour l'inline assembleur (qqchose qui fonctionne mieux que le asm de GCC, qui ne comprend pas l'assembleur inline).
# on décrit quelques règles de manières déclaratives en demandant à la mac
Posté par dinomasque . Évalué à 6.
http://fr.wikipedia.org/wiki/Prolog :
BeOS le faisait il y a 20 ans !
# je veux plus un langage ou une syntaxe
Posté par Gniarf . Évalué à 5.
moi depuis longtemps je préfèrerai assembler graphiquement des bouts de code comme ici :
http://llk.media.mit.edu/projects/scratch/help/images/greate(...)
ou
http://llk.media.mit.edu/projects/scratch/help/images/mouseY(...)
(un bout de code associé au sprite/acteur du chat)
le projet pédagoqique Scratch http://scratch.mit.edu/ est sous licence MIT et s'il ne tourne pas encore officiellement nativement sous Linux, on en est bien proche :
http://scratch.mit.edu/forums/viewtopic.php?id=252
il tourne déjà sous Wine et le port est plus que possible (basé sur Squeak, on peut déjà ouvrir l'image avec une machine virtuelle Squeak, ce qui ne marchera pas de suite ça sera quelques détails multimedia)
et voici d'ailleurs un pacman :
http://img259.imageshack.us/img259/9456/pacmanmc4.png
on notera que le "code" est localisable automatiquement et que sa structure reste inchangée.
je ne pense pas qu'il soit très dur d'imaginer des blocs pour gérer des tableaux, listes, maps et autres collections. actuellement on peut se créer des variables de type numérique (qui est déjà massivement utilisé pour la position et la direction des sprites) mais on s'aperçoit vite qu'elles sont peu nécessaires. ah, on peut envoyer des messages entre acteurs, aussi...
il doit être trivial de réunir et nommer des tas de blocs ordonnés pour en faire d'autres blocs ou superblocks réutilisables : je veux dire par là que cet aspect est un grand classique qu'on retrouve dans d'autres environnements d'assemblage de blocs ou composants logiciels.
maintenant on pourrait se creuser la tête sur comment créer des blocs supplémentaires dans cet environnement, à partir d'autres blocs et sans trop aller les coder en Smalltalk derrière : par exemple pour régler le volume : ce bloc manque, il faudra bien disposer d'une primitive setVolume...
[^] # Re: je veux plus un langage ou une syntaxe
Posté par Ontologia (site web personnel) . Évalué à 2.
Par contre au niveau sémantique, on découvre un ajout hyper intéressant auquel je pense souvent, et qui est un peu dans la lignée de Prolog : le "forever" que l'on trouve ici.
On exprime des contraintes, à l'interpréteur de se débrouiller.
Le problème, c'est que l'on peut tomber dans des contradictions logique. Donc soit l'interpréteur permet de détecter qu"il y a problème, soit on a carrément un moteur logique qui va essayer de le détecter à priori
Le développement d'une librairie est fondamentale, car c'est avec elle que se structure une taxinomie/ontologie, ou tout au moins une structuration des concepts de façon à être réutilisables.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Les mathématiques Formels
Posté par wistiti67 . Évalué à 2.
Partant du principe que dans les mathématiques, toute les équations sont démontré et on est sûr qu'il n'y a pas d'autres solution possibles que celle connu (ouai bon je maîtrise pas trop, je vous dis ce que j'en ai compris), ils espèrent à terme débouché sur la programmation de logiciels totalement dépourvu de bug. (belle utopie ;-) )
Cela débouchera certainement sur un nouveau langage de programmation, bien que dans l'article ils ne parlaient que de la "manière" de concevoir un logiciel (phase d'études préliminaire et tout ça)
En tout cas, si jamais ça débouche sur quelques chose d'intéressant, comme cette techno sera certainement matraqué de brevet, j'espère que l'ont verra quelques chose de similaire en libre bien avant les premiers résultat de leur techno pour qu'ils nous accusent pas de piller leurs propriété intellectuelle.
[^] # Re: Les mathématiques Formels
Posté par fmaz fmaz . Évalué à 5.
L'idée est d'utiliser la correspondance de Curry-Howard.
En math, on démontre souvent des trucs du genre: A implique B.
En info, on code souvent des fonctions qui prennent A et qui rendent B.
Si on réinterprète les maths, le théorème A implique B, ce n'est rien d'autre qu'une fonction qui, à partir d'une preuve de A, te rend une preuve de B. C'est la même chose.
En brodant un peu (beaucoup), on obtient un truc comme COQ qui permet de générer du code certifié. La seule chose, c'est que le mode de programmation est carrément spécial.
Exemple, pour programmer un tri, on démontre le théorème suivant:
Il existe une fonction f de l'ensemble des listes dans l'ensemble des listes telle que
- f(l) est une permutation de l
- f(l) est triée.
Une fois le théorème démontre, on peut demander à COQ de sortir du code implémentant une fonction qui vérifie les hypothèses du théorème: un tri.
Bref, le jour où les programmeurs de base sauront utiliser ce genre d'outil n'est pas encore arrivé.
[^] # Re: Les mathématiques Formels
Posté par outs . Évalué à 3.
Ce n'est pas spécialement breveté peut-être car c'est plus un domaine universitaire que industriel. Néanmoins de véritable application industriels on déjà été réalisé surtout dans le domaine des logiciels embarqués (train et avion notament). (et il risque d'en avoir de plus en plus, surtout si un jour des gens meurent à cause d'un controleur mal foutu dans une voiture).
La partie méthode formelle du labo Microsoft/INRIA va probablement être basé sur TLA, étant donné que son créateur Leslie Lamport est associé au Labo. http://en.wikipedia.org/wiki/Temporal_Logic_of_Actions (enfin j'en sais rien je fais de la rumeur c'est tout)
[^] # Re: Les mathématiques Formels
Posté par Vador Dark (site web personnel) . Évalué à 1.
[^] # Re: Les mathématiques Formels
Posté par outs . Évalué à 1.
Quand au marché potentiel, cela dépend juste de prix potentiel d'une erreur dans le logiciel (en perte humaine ou juste financiere) par rapport au surcout de dévelloppement.
Et si il sagit juste de faire un peu de model-checking ca coute pas non plus très cher.
[^] # Re: Les mathématiques Formels
Posté par MiniMoi . Évalué à 2.
Le logiciel de contrôle tourne sous Windows XP !
Si, si, je vous assure, vous ne rêvez pas, ou plutôt vous ne cauchemardez pas. Bon je tiens à préciser que c'est un "petit" réacteur, pas plus de 700kW de puissance, mais son clône est juste à côté et développe tout de même 70MW. Par contre je ne peut rien dire pour l'autre, j'ai vu la salle de contrôle, mais je ne me suis pas approché assez près pour pouvoir vérifier si c'est le même logiciel qui tourne dessus.
Bon, avant que vous ne fassiez une syncope, je précise (ce qui va dans le sens de outs) que le système informatique est juste un "bonus" ou un "front-end" des systèmes électroniques, qui sont bien entendu tous doublés, et absolument pas dépendants de Windows. Donc en cas de crash ou de comportement erratique de Windows, le contrôle est toujours assuré, et les sécurités toujours en place.
Après pour le reste de leurs réacteurs je ne sais pas, mais ça m'a choqué de voir du Windows en salle de contrôle, même d'un petit réacteur de recherche fonctionnant par intermittence (pas le nuit, par exemple).
[^] # Re: Les mathématiques Formels
Posté par Vador Dark (site web personnel) . Évalué à 2.
[^] # Re: Les mathématiques Formels
Posté par MiniMoi . Évalué à 2.
Toutes les mesures d'urgences sont automatiques, dans le sens où en cas de mesure indiquant un problème aucun choix n'est laissé au technicien, il y a arrêt d'urgence *(chute des barres de contrôle). Et je n'ai pas demandé, mais il n'est pas exclu qu'un crash de Windows entre dans ce cas (mais dans ce cas leur réacteur doit souvent s'arrêter... ;-)
De plus même en cas de défaillance totale, le réacteur s'arrête. En fait les barres de contrôle sont retenues par des éléctroaimants, donc si il n'y a plus de courant, elles tombent. Donc dans le pire du pire des cas, il faut juste couper l'alimentation électrique et la réaction s'arrête.
Il y a des règles de sécurité très strictes pour ce genre d'installation, et une de ces règles stipule que l'exploitant doit démontrer que le réacteur doit se mettre dans une configuration sûre en cas de problème.
Mais néanmoins, ça fait un choc...
* Et ce genre de chose se produit environ 3-4 fois par an sur le réacteur OSIRIS, dixit un ingénieur travaillant dessus
[^] # Re: Les mathématiques Formels
Posté par Sylvain Sauvage . Évalué à 2.
[^] # Re: Les mathématiques Formels
Posté par outs . Évalué à 1.
[^] # Re: Les mathématiques Formels
Posté par Vador Dark (site web personnel) . Évalué à 3.
# Erlang ?
Posté par forc3 . Évalué à 5.
Erlang.
Ce langage dispose de certains avantages et des fonctionnalités que tu décris plus haut.
Non seulement il est robuste, simple et ultra productif, mais en plus il vient avec un framework très très attractifs. (OTP)
C'est un langage fonctionnel, et peut dérouter les débutants ou expérimentés aux cerveaux encore trop habitués aux autres langages.
Erlang, dispose de 'green threads' c'est à dire de process ultra légers, ce ne sont pas le même threads que dans java ni celle de pthread ou de nptl, ce sont des processus erlang.
Un processus erlang pèse 300 octets, et une machine virtuelle de base (sans paramètre de démarrage) est configurée pour faire tourner un peu plus de 32000 processus.
Il est courant d'avoir un très grand nombre de processus tournant en même temps.
Pour vous donner une idée, un crawler de page web peut tout à fait être développé de manière à avoir un processus erlang par url à récupérer. En d'autres termes chaque href contenu dans une page va déclencher un "spawn" (fonction de création de processus) d'un processus faisant une requète GET.
Donc 5000 liens dans une page va déclencher 5000 processus...
Erlang est distribué, pour communiquer la syntaxe est très simple, les processus sont identifiés par leur PID et pour leur parler on écrit ceci:
Pid ! coucou.
Cela veut dire qu'on envoit l'atome coucou au processus Pid.
Pid peut être sur la machine locale comme sur une autre machine, c'est transparent...
Erlang dispose des List Comprehension, du Pattern Matching, d'une base de donnée repliquée et distribuée (Mnesia).
Erlang dispose également de modules indispensables, tableaux (ets, dets), arbres (gb_sets, gb_trees), gestion de queue (queue), de timers (timer) et bien d'autres.
Erlang dispose de types de bases proches de ceux du javascript (pardonner cette phrase mais elle permettra à plus de monde de comprendre :p), liste et tuple.
[1,3,4,5,2] est une liste
{user, Login, Pass} est un tuple
[{a, 1}, {b,2}, {c,3}] est une liste de tuple...
Erlang c'est aussi un moyen de faire de la livraison de code à chaud, Erlang fait la différence entre les versions de codes, il est donc capable d'être mis à jour sans arrêt. No DownTime.
Erlang vaut définitivement le coup d'oeil, il est facile de dire que ce language va faire énormément parler de lui dans les années avenir, ne serait-ce qu'avec l'arrivée de processeur multicore... (pour comprendre il faut regarder en détails et arriver à comprendre qu'une variable ne peut pas changer de valeur une fois assignée...)
Une Vidéo sur le sujet, certainement le plus accessible:
google video
Certains projets commencent à être connu (ou le sont déjà):
Ejabberd (process-one)
Tsung
Eddie
Doc Erlang:
Erlang.org
Intro a Erlang (en anglais)
Et pour approfondir, n'hésiter pas à chercher sur del.ico.us ou digg ou reddit, ou encore l'excellent Lambda the Ultimate
[^] # Re: Erlang ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Erlang ?
Posté par forc3 . Évalué à 3.
En revanche j'admets tout à fait que pour la gestion des caractères sous forme de liste peut sembler être lourd, c'est le cas, mais c'est également pour cette raison que le type binary est utilisé (notation en << >>).
Maintenant il est toujours (et peut importe le language) de générer un automate pour parser un fichier XML que d'utiliser DOM, XPATH et tout ce que tu veux.
Je défis quiconque de réaliser un parser avec libxml2 pour ne citer que le meilleur, qui irait plus vite qu'un code générer à partir de flex (même pas besoin de bison/yacc) pour parser exactement les même tags...
Et oh grand bonheur, dans le code source de erlang tu peux trouver l'application megaco qui utilise justement un parseur générer à l'aide de flex, tout simplement pour des soucis de performances (et certainement de rapidité de développement pour le ou les auteurs).
ejabberd utilise libexpat pour parser son XML.
Dernier point, même si me prouve qu'à traitement équivalent erlang est plus lent, lorsque tu veux augmenter ta puissance de calcul en ajoutant des noeuds à ton réseau je peux te garantir qu'erlang au final l'emportera.
Regarde du côté du MapReduce ( de google ) et essai peut être de comprendre que la vitesse n'ai absolument pas le but ultime, le but ultime c'est d'avoir une plateforme
dans laquelle tu peux
ajouter 1 noeud, retirer 1 noeud quand tu veux et sans perturber le service,
une plateforme qui peut grossir horizontalement.
Un noeud (une machine on va dire) utilisé à 100% de sa puissance à 100% du temps est une énorme erreur.
Ce noeud ne pourra pas encaisser une charge soudaine, devient difficile à administrer (pense à toute les sondes de surveillance système et métiers) et est primordiale à la plateforme, c'est à dire que si elle tombe les autres machines de la plateforme ne pourront tenir la charge globale...
Erlang c'est pour bâtir des architectures solides dans un monde où 100% du temps seul 90% (on va dire) du matériel fonctionne...
Cadeau bonus:
études de cas
Ce lien ne parle pas d'erlang en particulier mais d'architecture, et la conclusion est que le brique qui ont été nécessaires existent ou sont triviales à implémenter en erlang...
[^] # Re: Erlang ?
Posté par forc3 . Évalué à 1.
La video google:
http://video.google.com/videoplay?docid=2953846492344274158&(...)
http://www.erlang.org/
Lien vers les presentations des archis (dans le vent) web 2.0:
http://poorbuthappy.com/ease/archives/2007/04/29/3616/the-to(...)
[^] # Re: Erlang ?
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
On connais tous les limites des programmeurs quand il s'agit de concevoir un code qui s'exécute dans plusieurs flots. Et c'est peut-être là le problème majeur ?
[^] # Re: Erlang ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En plus, il me semble que Erlang tourne dans une VM pas encore jit et pas encore SMP aware. Bref, j'imagine que même Perl ou Java doit être plus rapide.
En gros à part dans les applications serveur ou le parralèlisme est trivial, Erlang pourrait s'en sortir. Et encore, faire de la distribution de charge sur plusieurs apache n'est pas bien difficile et chaque noeud sera bien plus rapide.
"La première sécurité est la liberté"
[^] # Re: Erlang ?
Posté par Vivi (site web personnel) . Évalué à 1.
tout faux: il y a un compilateur natif et le runtime est SMP-aware (mais ça fait pas longtemps il est vrai)
[^] # Re: Erlang ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Erlang était très bon pour le paralèlisme par la VM executait une instruction par thread après l'autre. Le compilo ne peut pas faire ça. Il utilise les threads de base de l'os?
"La première sécurité est la liberté"
[^] # Re: Erlang ?
Posté par forc3 . Évalué à 2.
un processus erlang prends 300 octets, et n'est pas un appel a fork() ni à pthread_create ou à clone().
Erlang utilise les thread pour se répartir sur les différents core des processeurs, mais une thread OS peut contenir 30000 process erlang...
Plus je lis vos commentaires et plus je vois qu'il circule un mythe sur erlang.
Erlang dérive des telco, c'est à dire qu'il doit assurer 99,99999 % de disponibilité.
Erlang n'est pas un language sorti d'une université, erlang est la réponse à un besoin,
et c'est fondamentalement différent des autres langages.
Ericsson avait besoin d'un langage robuste, sûre et permettant le développement rapide.
Pour les perfs, il existe le très connu:
http://www.sics.se/~joe/apachevsyaws.html
Yaws étant un serveur web écrit en erlang.
Encore pour les perfs, la meilleure implémentation de serveur Jabber n'est autre que ejabberd. Or un serveur Jabber regroupe exactement toute les problèmatiques liés au développement réseau (concurrence, asynchronisme, performance, stabilité)
Sinon erlang au passage ca tourne sur énormément de pabx ericsson, ou switch/accelerateur SSL nortel ...
Altéon également utilise erlang.
Pour terminer, il n'existe pas d'avenir pour les langages qui continue à
partager des variables, (Mutable State is Hell)
ne font pas de la concurrence de base,
ne peuvent pas être rechargé à chaud,
et ne gèrent pas les grappes de machines de manière transparentes....
[^] # Re: Erlang ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
un processus erlang prends 300 octets, et n'est pas un appel a fork() ni à pthread_create ou à clone().
Erlang utilise les thread pour se répartir sur les différents cores des processeurs, mais une thread OS peut contenir 30000 process erlang...
En gros les 300 octets, c'est la taille prise même si le nouveau thread contient uniquement un "RET". La taille réservée pour la pile et le code sera bine plus grande.
Erlang dérive des telco, c'est à dire qu'il doit assurer 99,99999 % de disponibilité.
Je le sais bien. On peut même rajouter que les performances n'étaient qu'un problème secondaire, c'est pour ça que je considère que cela n'est qu'un langage de niche.
Et cela n'est pas ce que l'on demande principalement à un langage actuellement (c'est plutôt de la productivité, et un moindre cout de formation).
Le bench montré n'a que peut d'interret. Pour ce genre de serveur, c'est le nombre de requètes par seconde en fonction du nombre de session en parralèle qui est la métrique utilisée.
Je parie que Erlang doit très bien scaler jusqu'à plus de 30000 sessions parrallèle avec une courbe bien plate. Mais que pour les cas d'utilisation moyen avec ~100 à 1000 sessions, je parie que apache gère bien plus de transactions.
"La première sécurité est la liberté"
[^] # Re: Erlang ?
Posté par briaeros007 . Évalué à 2.
Erlang a appris l'existence de librairies de threads MxN.
C'est normal pour un langage orienté concurrence aussi :D
Et voui ce genre de librairie existe aussi en C par exemple.
(je ne dis pas que erlang ca pux car il a des avantages indéniables, je dis juste que les threads MxN erlang est pas le seul a pouvoir les utiliser).
Question sur erlang : la migration de processus se fait comment :
- a travers la meme machine (smp)
- a travers un cluster (machine numa) voir un bewolf (grille de calcul, ...) ?
Comment est gérer la mémoire ?
Evite -on les faux partages ?
# L'algorithme.
Posté par kowalsky . Évalué à 2.
problème, ça ne reste pas l'algorithme ?
Bien sur, un bon langage va permettre de modéliser les choses
de belle façon, mais à un moment, il faut tout de même
penser à l'algorithme, à l'empreinte mémoire etc...
[^] # Re: L'algorithme.
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Typiquement tu as trois étapes.
_ Tu écrit un algorithme dans un langage
_ Celui-ci est transformé en un objet mathématique (un graphe)
_ le graphe devient un flot d'instructions machine
La question est plus de savoir comment est-ce qu'on peut envisager les choses différemment.
Certains langages le permettent. Par exemple en prolog tu définis une série de contraintes.
Tout fils a un père et une mère.
> a est le fils de b
> c est le père de a
>>>>>>>> b est la mère de a
Un bon exemple est la différence de raisonnement entre : remplir une grille de sudoku et résoudre une equation
Un autre exemple une base de données.
Tu crée un univers : la base avec ses contraintes, sa façon de fonctionner, ses droits ...
Ensuite tu agis sur cet univers avec un langage prévu exprès pour ça : le SQL.
C'est aussi une façon de programmer.
Là, il n'est nullement question d'algorithme mais bien d'une façon d'envisager les choses.
[^] # Re: L'algorithme.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Ca fait le backtracking tout seul, certes, mais si t'es pas foutu de bien de bien definir tes contraintes (ou si elles sont pas triviales), t'as vite fait d'ecrire du code facile et rapidement, mais ultra pas efficace, voire pire !
Pour les langages proches de l'humain mais pour l'ordi, j'ai lu un article dessus recemment, le (peut etre) bien nomme EasyLanguage : http://lambda-the-ultimate.org/node/2201
Mais bon, perso, après de l'ASM, du C++, du Caml et du Haskell (et tout plein d'autre sur mon CV), c'est avec Scheme que je redécouvre le langage idéal.
# Inform?
Posté par David Anderson . Évalué à 2.
Bien sur, ce n'est pas tout à fait de l'anglais, des fois les constructions sont un peu lourdingues, mais c'est vraiment un plaisir de décrire une aventure en utilisant ce langage, plutot qu'en composant des objets avec attributs et méthodes, comme il fallait le faire avec Inform 6.
Voila :)
# j'pige pas tout mais j'me soigne
Posté par Grumbl . Évalué à 0.
http://www.sgi.com/tech/stl/stl_introduction.html
[^] # Re: j'pige pas tout mais j'me soigne
Posté par z a . Évalué à 6.
# Le plus gros défi...
Posté par MiniMoi . Évalué à 2.
Un bon langage adapté au futur sera un langage qui permette d'écrire "naturellement" des applications multithread, mais je n'en connais pas à l'heure actuelle... (cependant il est vrai que mes connaissances en terme de langages sont limitées)
Je suis vraiment convaincu par les mérites des langages fonctionnels, mais par exemple OCaml ne permet pas grand-chose dans le domaine du multithreading, hélas. Je ne sais plus très bien où (sur la ML de OCaml il me semble) j'avais vu que les concepteurs du langage sont opposés à ça, tant qu'il n'y a pas de paradigme efficace de programmation concurrente.
Qu'en est-il ?
N'y-a-t-il pas au contraire un espoir suscité par les langages fonctionnels ?
Il me semble en effet qu'un programme écrit d'une certaine façon en fonctionnel peut être parallélisé très facilement, par exemple un truc du genre :
let rec f l =
match l with
|[] -> []
|x::r -> (quelque_chose x)::(map f r) ;;
En gros faire du MapReduce...
[^] # Re: Le plus gros défi...
Posté par lasher . Évalué à 3.
Je ne suis pas d'accord avec cette vision des choses. La prog concurrente existe indépendemment des threads. De plus, on peut très bien avoir des threads de niveau utilisateur qui se coordonnent très bien, voire n'ont absolument pas connaissance de l'existence des voisins, car l'ordonnancement a été fait pour.
[^] # Re: Le plus gros défi...
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Erlang et Gambit-C/Termite (Scheme)
Ton truc s'appelle pmap
parmap(F, L) ->
Parent = self(),
[receive {Pid, Result} ->
Result end ||
Pid <- [spawn(fun() -> Parent ! {self(), F(X)} end) ||
X <- L]].
(define (pmap f lst)
(let ((parent (self)))
(map (lambda (pid)
(recv ((,pid reply) reply)))
(map (lambda (x)
(spawn (lambda () (! parent (list (self) (f x))))))
lst))))
Pour caml, c'est pas l'objectif du langage. Mais tu peux regarder du coté du "join calculus" qui a été implanté en OCaml...
# Smalltalk
Posté par Nicolas da Luz Duque . Évalué à 2.
C'est un langage à la syntaxe super simple, super orienté objet, et avec un minimum de rigueur super lisible. On peut aussi passer des blocs de code en argument, faire de la réflexivité et ce genre de truc (méta-programmation, ...).
En plus, grâce à l'ultra-simplicité de la syntaxe, il est super facile de faire des outils de refactoring puissants, ce qui rend la programmation beaucoup plus agréable et ce qui permet de se concentrer vraiment sur les choses importantes comme le design de l'application. Après, c'est d'autant plus facile de rajouter des fonctionnalités et de faire évoluer le code. (Si on couple ça avec une batterie de tests unitaires, on est partis pour conquérir le monde!)
Depuis que j'ai découvert ce langage, j'ai l'impression que tout ce que j'ai fait avant (C, C++, java, etc) c'est de la merde.
Python ça va encore ;-)
Faut encore que j'essaye Ruby, aussi.
[^] # Re: Smalltalk
Posté par Ontologia (site web personnel) . Évalué à 2.
Lisaac s'inspire de Smalltalk, Self, Eiffel. Il est lui aussi un langage minimaliste (moins de 10 primitives de base) et propose une syntaxe à mot clé.
La réflexivité devrait être proposé dans moins d'un an, ce qui fera de lui un total sur-ensemble de SmallTalk.
Lisaac est compilé et permet d'atteindre des performances proche du C.
Il devrait normalement être libéré un jour.
http://isaacproject.u-strasbg.fr/li.html
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Smalltalk
Posté par Mildred (site web personnel) . Évalué à 2.
Le un jour a l'air d'être dans vraiment pas longtemps.
En gros c'est déjà libre mais ce n'est pas encore publié ... Il faut attendre la version 0.2 qui devrait logiquement bientôt sortir.
# Perso
Posté par outs . Évalué à 1.
Devoir tout taper dans des vielles syntaxes genre SQL ou windev, mon dieu quel horreur :)
En plus, comme dit plus haut, l'informatique est une science dure et en temps quel tel le seul langage qui pourrait rassembler tout le monde, ben c'est le langage des math (formelle). la logique quoi. (mais pas forcement un langage genre prolog : qui est quand même très special dans l'idée).
Enfin c'est juste mon point du vue.
[^] # Re: Perso
Posté par Ontologia (site web personnel) . Évalué à 2.
Mon propos est d'essayer d"imaginer de nouveaux paradigme afin de diviser par n les coûts de développement.
Ca peut chagriner des informaticiens qui voient le fondement de leur présence, potentiellement se dérober sous eux à la vue d'une telle perspective.
Juste entre parenthèse sur Windev, j'en ai fait pas mal, je connais, et windev, c'est une sorte de langage pascal interprété, mais c'est très classique comme langage, la grammaire est just un peu neuneuifié.
SQL est par contre assez génial, parce que ma chef, qui était contrôleur de gestion, et donc pas informaticienne, a assez facilement appris à faire diverses requêtes : SQL est logique, simple d'accès et ne te demande pas d'expliquer à la machine ce qu"il faut faire.
En plus, comme dit plus haut, l'informatique est une science dure et en temps quel tel le seul langage qui pourrait rassembler tout le monde, ben c'est le langage des math (formelle). la logique quoi. (mais pas forcement un langage genre prolog : qui est quand même très special dans l'idée).
Moi je fais de l'informatique de "gestion" tout les jours et je peux te dire que c'est partiellement vrai, les concepts qu'on exprime sont certes mathématiques au fin du fin, mais il existe certainement des manières moins mathématique et aussi rigoureuse - faisant appelle à l'intuition - de l'exprimer.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Perso
Posté par outs . Évalué à 2.
Haha Ontologia t'es trop fort:) Et toi avoue que tu aime les grandes phrases pleines de mots pompeux :)
Mais je pense réellement que le langage naturel n'est pas le meilleur candidat pour démocratiser les choses.
Le langage mathématique parrait abscon pour pas mal de monde je sais. Mais en fait il est définit avec une dizaine d'opérateurs de base que l'on combine en utilisant, la plupart du temps, son intuition pour exprimer ce qu'on veut.
Si on utilise un langage naturel pour le remplacer, cela va sembler plus simple mais en fait la difficulté sous jacente sera la même. Et il vaut mieux avoir un langage non-ambigu pour s'en sortir avec ces difficultés. C'est un petit investissement a faire pour se simplifier la vie apres.
Uniquement parcqu'il est basé sur l'algèbre relationnelle. La couche de bla-bla pardessus ne fait que rendre les choses plus confuses. Enfin en tout cas c'est la premiere chose que j'ai ressentit apres avoir apris a rédiger les requetes en algebres relationnelle directement et en SQL. Je me souviens plus mais y'a une demi-douzaine d'opérateur a apprendre en algebre et c'est tout. Alors qu'un manuel SQL c'est plein de cas particulier et de bordel.
Apres plein de gens sont rebuté par les notation mathématique, je pense que c'est un problème pédagogique plus qu'autre chose.
enfin au final, si on considère que tout le monde n'a pas la même représentation mentale cela serait normal que des gens préférent un style et d'autre un autre. Et le mieux serait que chacun puisse utiliser son langage adapté a se représentation et que l'on ai une interopérabilité voir pourquoi pas un moyen de traduire automatiquement d'un langage vers un autre.
# Autres grammaires
Posté par Mildred (site web personnel) . Évalué à 2.
A ce propos, j'avais en ce moment une idée de créer un langage sans syntaxe définie, mais où la syntaxe serait définie lors de l'exécution. Bien sûr, au début du fichier, une dyntaxe par défaut serait chargée mais il serait possible d'en changer après.
Je pensait à un truc du style LaTeX avec des caractères reconnus qui permettent de structurer le texte, mais où il serait possible de changer ces caractères en cours de route tout simplement.
Après, c'est juste une idée que je n'aurais sans doute jamais le temps d'implémenter.
[^] # Re: Autres grammaires
Posté par Moonz . Évalué à 2.
[^] # Re: Autres grammaires
Posté par Mildred (site web personnel) . Évalué à 2.
On appelle la fonction \define qui va définir un symbole my_function contenant une fonction qui affichera son premier paramètre. Ensuite, on définit que le caractère @ servira a introduire un mot-clef comme le fait actuellement \. On peut donc appeler notre fonction définie avec @my_function.
Pour déterminer les paramètres d'une fonction cela se fait à la volée. Lorsque une fonction appelle getparam, le moteur du langage va découper le texte qui suit le texte en cours (@my_function), c'est à dire {Hello World}. Il détecte les caractères spéciaux { et } qui permettent de grouper le texte et prend uniquement son contenu. Le contenu trouvé est ensuite évalué récursivement.
Il serait bien sûr possible d'accéder au prochain caractère de manière brute ou sans évaluer le texte trouvé. Sinon, si dans mon appel à \getparam j'ai mis {\true} c'est pour dire que le paramètre doit être 'mangé' et que le procian texte a évaluer est encore après.
Voila, j'espère que ce n'est pas trop difficile a suivre
[^] # Re: Autres grammaires
Posté par Mildred (site web personnel) . Évalué à 2.
Je pensait écrire ça en Lisaac.
Le problème c'est que j'ai aussi d'autres projets tout aussi intéressants en tête et que je n'ai finalement que très peu de temps.
[^] # Re: Autres grammaires
Posté par Sylvain Sauvage . Évalué à 2.
Par exemple, en Common Lisp, on associe le caractère tilde ~ avec la fonction ‹tilde-reader› avec cette petite ligne :
(set-macro-character #\~ #'tilde-reader)
La fonction ‹tilde-reader› lit le flot correspondant à la suite du code en cours de lecture (on utilise la fonction ‹read› et on récupère le texte, non-évalué, et on construit une s-expression (du code) qui sera évaluée).
Tu peux aussi faire d’autres modifs, pour remplacer la signification des parenthèses, en donner aux chevrons (pour le XML…), etc.
Tout est possible en Lisp parce que Lisp n’est qu’une boucle read-eval-print (ou (print (eval (read))) :o) et que l’on peut modifier toutes les fonctions, y compris ‹read›, ‹eval› et ‹print›.
On le fait pour utiliser Lisp comme machine virtuelle d’un langage ad hoc.
On ne le fait pas vraiment pour des données (comme du XML) parce que ça ne simplifie pas vraiment le code. Tout ce que ça apporte, c’est le « wahou ! les données _sont_ le code », qui, une fois passé l’auto-satisfaction, entraîne un « et alors ? »…
Finalement, ça n’est pas très différent et ça n’apporte pas grand-chose à l’utilisation de compilateurs ou d’interprètes ad hoc.
[^] # Re: Autres grammaires
Posté par Mildred (site web personnel) . Évalué à 2.
J'ai déjà pensé à utiliser un langage lisp. Mais je pense préférer le scheme (plus petit et je trouve mieux sur certains aspects) mais ce langage me rebute par le fait que l'environnement global contienne *beaucoup* de variables (guile en contient plus de 1000 par défaut).
Je préfère quand même partir sur quelque chose de déconnecté de Lisp qui a plein d'avantages mais aussi je trouve quelques inconvénients. Mais pour le moment je travaille sur autre chose alors on verra plus tard.
[^] # Re: Autres grammaires
Posté par Sylvain Sauvage . Évalué à 2.
Il fut un temps où j’ai aussi pensé à faire un langage de documents à la TeX mais en évitant ses problèmes. Par exemple :
— le fait que TeX est un langage de macros, ce qui est déjà difficile à suivre avec l’utilisation répétée de \expandafter (‹quote› en Lisp, mais qui n’opère que sur le caractère ou la commande qui suit) ;
— avec de vraies macros, celles qui sont évaluées dans le « ventre » de TeX, pour reprendre les termes de Knuth, et des macros spéciales, qui sont évalués dans sa « bouche » ;
— le manque de primitives pour manipuler les chaînes (bonjour la chienlit pour découper une chaîne).
Bien sûr, on arrive à faire plein de choses, surtout quand on s’appele Knuth, mais ce n’est vraiment pas par le chemin le plus accessible.
La syntaxe (La)TeX n’est pas si sale (même si elle est perfectible, mieux structurable) et XML est effectivement trop lourd si c’est un humain qui doit le taper.
Par contre, dès qu’on y réfléchit un peu, on voit que c’est une tâche colossale : il y a énormément de bibliothèques à faire pour arriver à la cheville de LaTex et il est plus simple de s’accommoder de ses défauts.
[^] # Re: Autres grammaires
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Autres grammaires
Posté par Sylvain Sauvage . Évalué à 2.
[^] # Re: Autres grammaires
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
euh... mais si tu prends guile, t'étonne pas d'avoir un truc si gros...
(en plus, guile est pourri, mais c'est une question de gout)
Regarde plutot du coté de Scheme48 pour un Scheme plus petit.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.