Reprise du message précédent :
ce langage marque un point

 
Merci pour le premier lien.
 
La seconde édition du dragon est trop chère pour ma bourse :x

 
j'adore très pratique  

La première reste très bien, et elle se trouve pour un peu moins cher d'occase (après, je dirais que le Dragon Book reste une vraie de vrai référence, et vaut donc son prix)

Ouais, les langages dérivés du C quoi. Parce que les langages pas dérivés du C, ils ont en majorité pas exactement ce genre de commentaires

edit: je viens de lire la page d'intro, j'aime bien la dichotomie entre les procédures et les fonctions (...), le fait qu'on ne puisse pas checker la taille des arrays (mais qu'il y ait quand même un concept d'OOR \o/) et les bonnes vieilles itérations à l'ancienne (\o/ \o/)

Et naturellement, "un booleen, c'est jamais qu'un entier".

D'ailleurs, il se passe quoi si on balance "78" dans un contexte booléen?

Il me semble que le fait de faire la disctinction entre les notions de procédure et de fonction n'est pas forcément mauvais.. d'ailleurs certains autres langages la font cette distinction, comme l'ADA et certainement d'autres. De toute manière, ce n'est pas gênant (ça me semble plus propre, mais c'est que mon point de vue...).
 
La taille des tableaux, ça se fait en deux secondes, je ne l'ai juste pas encore implémentée cette fonction Les itérations du genre i++ au lieu de i=i+1, c'est pas encore fait, mais je peux le faire. C'est une toute première version hein
 
Pour le booléen, c'est faux si différent de zéro. Donc 78 retournera vrai, comme dans le langage mIRC Script d'ailleurs (en fait j'ai énormément programmé en mIRC Script dans le passé, et j'adore ce langage pour beaucoup de raisons. Et le fait de pouvoir évaluer des entiers comme des booléens n'a jamais posé de problèmes dans les scripts que j'ai pu réaliser auparavant).

 
Oui, saut de ligne si vrai. C'est écrit dans la doc

C'est tout aussi horrible

On est plus en 1970 hein

Même java a bougé, c'est dire

Pouvoir évaluer les entiers dans un contexte booléen et être obligé de passer par des entiers parce qu'on a pas de booléen sont des choses très différentes.

Masklinn, que proposes tu ?  
Que prefererais tu avoir à la place ?    

Soit des iterators inclus au langage, comme en python (ou en Java depuis 1.5, ou en C#, ...), soit une gestion de l'itération via appel de méthodes & fonctions de haut ordre comme en Smalltalk ou en Ruby.

Ou alors pas d'itérateurs, et une gestion du concept via récursion et fonctions de première classe comme dans la majorité des langages fonctionnels.

Au vu de la doc et des exemples, et sachant que ce petit projet a été commencé il y a juste 3 mois à peine, je trouve ça vachement impressionnant.
 
Chapeau !

Ca veut dire quoi, G?

Je ne m'occupe pas de faire des remarques sur les prototypes des fonctions, qui n'est qu'un détail dans un premier temps, et pas non plus de la syntaxe (language régulier ou non, etc...)
 
Quelques commentaires à la volée :
- un langage sans capacité modulaire (modules, librairies, etc...) n'est pas utilisable en dehors de micro scripts
- l'absence de notion de référence à (ou de pointeur sur) va vite limiter les structures de données faisables (liste chainées, ...)
- gestion de fichiers/sockets sans un identifiant explicite donné lors du open est un peu bizarre, je ne connais pas de language qui marche comme cela
- j'espère que le type bool c'est pas 0 ou 1, mais 0 ==> FALSE et que !=0 ==> TRUE
- pourquoi avoir fait une syntaxe déclarative compliqué des array array(type)[taille] nom_variable, et non comme 90% des langages type nom[taille]...
- je n'ai pas vu la notion de caractère spécial/échappement dans tes strings (et l'exemple de la fin sur le shellexecute me laisse penser qu'il n'y en a pas). Si c'est le cas c'est une erreur, il existe plein de "caractères" non imprimables ...
 
 
Sinon il est où le multithread?
 
Ensuite, l'avantage de pas mal de language de scripts c'est la fonction de type "eval" tu prévois d'en mettre une?
 
C'est vrai que c'est un bon exercice. Après, de la à trouver des utilisateurs, c'est autre chose :
- un langage, pour percer doit faire ses preuves dans le monde "pro"
- donc, en dehors de la bidouille, doit être supporté (bug fix, ...)
- à une seule personne, c'est impossible de le faire
- l'aspect mono envir (windows) va largement freiner son éventuelle adoption par d'autre (ahh les joies du monde unix)
 
Personnellement j'arrêterais là et je rejoindrais des communautés sur des langages existants (perl, ...) : ils ont toujours besoins de bras et la portée de tout dev sera tout autre...
 
Bon courage pour la suite,

 
Merci pour les commentaires.
D'abord, Ace17 -> G n'a pas vraiment de signification... j'aime bien cette lettre, et je l'utilise à toutes les sauces, pour mon pseudo, mes créations etc.
 
 - Pour ce qui est de la capacité modulaire, je prévoyais de faire des instructions du type "include", ce n'est juste pas encore implémenté.
 - Pour les pointeurs, il faut que j'étudie la question, mais si j'essaye surtout de faire un langage de scripts, alors ça ne serait pas vraiment utile.
 - Pour les fonctions de sockets, il y a bien un identifiant, mais pas sous forme de type "socket" ou ce genre de handles, mais sous forme d'une chaîne de caractères, tout comme en mIRC Scripting (oui, toujours lui )
 - En ce qui concerne les identifiants des fonctions de manipulation de fichiers, pour le moment je n'ai fait que des fonctions qui ouvrent et ferment un fichier au début et à la fin de l'instruction. C'est limité si on veut boucler sur un fichier, car à chaque passage de la boucle, ou ouvrirait et fermerait un fichier (en revanche c'est très pratique pour une utilisation ne nécessitant pas d'optimisation particulière ou si on ne veut pas se prendre la tête). Il faut donc que j'implémente des fonctions qui utilisent un identifiant de fichier, c'était prévu
 - Le type bool, comme je l'ai dit un peu plus haut, c'est bien 0 => FALSE, et != 0 => TRUE
 - Je trouve la syntaxe de déclaration de tableaux du langage G plus explicite que dans d'autres langages... mais bon, ce n'est qu'une histoire de notation.
 - Effectivement pour le moment il n'y a pas de notion de caractère spécial/échappement dans les strings du genre '\n' ou '\r'. Je peux effectivement y réfléchir. En tout cas pour le moment on est contraint de faire "char n = 13;" et "char r = 10;".
 - Pour ce qui est du multithread, pour le moment il n'y a que du basique de chez basique. Par exemple, pour lancer un thread, il suffit de préciser le mot-clé "thread" dans une déclaration de procédure. Il n'y a pas encore de notions de mutex ou de rendez-vous collectifs etc.
 
Je n'ai pas encore pensé à la fonction eval, mais je vais envisager ça...
 
Je pourrais faire un portage Unix car à la base j'avais commencé à créer mon interpréteur sur une plateforme linux, mais maintenant qu'il y a des fonctions de thread et surtout de sockets... ça demande beaucoup plus de travail, car les fonctions requises pour ces trucs là changent d'une plateforme à l'autre.
 
Merci pour tes encouragements

A quand les sources ?

Des langages de scripts sympa avec sources, il y en a pas mal. Outre les gros comme Python et Ruby, il y a les langages plus légers et d'extension comme Squirrel, Lua, io, ou certains basés sur une JVM comme Pnuts.
J'aime bien Pnuts, du fait de sa simplicité et de capacité à appeler directement les classes Java. Je l'ai déjà utilisé comme langage d'extension dans un projet professionnel. C'est simple et ça marche plutôt vite et bien. C'est typiquement l'outil qu'on peut intégrer sans soucis si on veut offrir la possibilité de faire du script dans son projet.

J'ai déja mis mon nez dans les sources de Lua
Mais j'ai pas pris le temps d'approfondir :x

 
Ce qui est un non-problème de nos jours avec genre boost::thread et d'autre lib d'encapsulation.

Tiens, personne n'a encore posé la question qui tue :
 
C'est quoi le framework que tu penses associer à ton langage ?
 
Dépendamment de tes objectifs, ça peut se faire en 1 jour comme en une vie (ie: jamais). Sérieux, on utilise pas un langage pour se masturber sur les constructions qu'on peut faire avec, mais bien pour faire une tâche (suffit de voir NSIS, 4D, WinDev, VB, ...). Alors, oui, dans la théorie, avec un langage Türing-complete tu peux tout faire, mais le framework fait vraiment la différence entre ce qui est réalisable en 1 jour ou en une vie (ie: jamais).
 
J'ai tendance à distinguer 2 mondes :

• Server : pas d'IHM. Framework moins conséquent, mais concurence très très rude.
• Client : IHM, graphisme 2D, voire 3D, etc ... j'ai déjà utilisé des frameworks proprio cross-plateforme (OS X et Win32) extrêmement compact (un peu limité quand même), on doit pouvoir faire un truc qui couvre 90% des besoins avec un minimum de code (pour avoir étudié un peu la question, ça doit être torchable en 20000 ou 30000 lignes de C, ce qui n'est pas énorme du tout). Mais c'est très très gore, va falloir plonger dans des API qui sentent le formol.

Ou avec un moindre effort : permettre l'appel direct à des DLL C (voire si tu es vraiment très très motivé, à des dll C++, l'ABI est au moins figé sur Win32).
 

mwai, autant utiliser groovy...

florentg

quelque chose de mieux a proposer ?

À peu près n'importe quoi dans ce qu'a cité much'

je parlait de langages basés sur la jvm

A voir. Groovy est celui qui fait le plus de buzz (avec Scala), pas sûr que ce soit à la hauteur. En tout cas, il ne l'était pas à l'époque où j'ai regardé, il y a 2 ans. Il avait reçu une très mauvaise pub de la part d'un blogueur bien connu en info, qui avait fait une comparaison pooussée des langages de script basés sur la JVM, en écrivant un jeu avec chacun d'eux. Il avait dû faire face à pas mal de bugs. Je suppose qu'il y a eu de l'amélioration depuis, mais ça n'était vraiment pas rassurant, avec des régressions entre versions. Sachant que le langage d'extension était destiné à l'usage du client, je ne pouvais pas me permettre d'offrir une version beta.
Pnuts, au contraire, ne fait guère de bruit, mais mériterait plus d'attention, car son auteur a réalisé un produit de qualité indéniablement professionnelle. Le langage est certes moins ambitieux. C'est un langage d'extension, donc léger, mais véloce (et quand je dis véloce, ça veut dire des perfs du même ordre de grandeur que Java pour ce que j'avais à lui faire faire), et avec suffisament de features pour être intéressant. Et surtout, il est parfaitement documenté, les libs bien pensées et assez complètes (surtout qu'on a toute la JDK si besoin) et je n'ai jamais eu de soucis avec. Je n'en demande pas plus.

Lua rulez pardi LuaJIT aussi

Ben Python, Ruby, Pnuts, ...

Ce qui me gène le plus dans groovy c'est qu'il n'y a pas de vision, pas de design, c'est du "me too"-ism au plus haut degré: les core dev voient des trucs qui marchent bien dans d'autres langages, donc ils les collent dedans sans trop se poser de question sur les conséquences à l'échelle du langage ou du design de celui-ci.

Et naturellement, comme il est basé sur la récupération il n'y a rien d'original, rien qui le démarque, et rien d'intéressant.

En plus, il est moche ce langage

Un nouveau coup d'oeil à Groovy permet de se rendre compte que ce langage semble chercher à être complètement substituable à Java.

Syntactiquement parlant.
 
C'était déjà le cas à l'origine, et je vois pas ça comme un avantage.

La seule syntaxe que Pnuts n'a pas de base, ce sont les list comprehesions, même s'il peut adopter le style fonctionnel avec le module "functional".

En revanche je n'ai pas vu dans la doc de Groovy l'équivalent de:

e.g. (util/mymap.pnc)
 
package util
import java.util.*
import java.io.*
class mymap extends TreeMap implements Serializable {
  get(key){
    if ((v = super.get(key)) == null){
      super.put(key, v = set())
    }
    v
  }
}

Autrement dit une classe Pnut qui sous-classe une classe Java.

e.g. (util/mymap.pnc)
 
package util
import java.util.*
import java.io.*
class mymap extends TreeMap implements Serializable {
  get(key){
    if ((v = super.get(key)) == null){
      super.put(key, v = set())
    }
    v
  }
}

Ben en Groovy tu subclasses une classe java comme tu subclasses une classe Groovy, donc comme en pnuts, d'après ce que j'ai compris

D'ailleurs normalement tu peux aussi le faire dans e.g. JRuby ou Jython.

et sinon, personne n'a testé ça ?
http://www.ibm.com/developerworks/ [...] 01228.html

J'ai regardé, un peu, de loin, histoire de voir ce qui pouvait se faire sur la JVM pour remplacer java (donc un langage compilé & typé statiquement)

À première vue, c'est vraiment très sympa Je suis pas en extase devant la syntaxe mais elle est bien meilleure que celle de Java, et l'intégration entre les concepts objet et fonctionnels est bien faite

En plus, il y a une lib d'Actors (le parallélisme à la Erlang)

ah ben ça me rassure, ça fait un petit moment que je m'interesse à ce langage, je le trouve assez sympa également

Moi j'attends un G#

d'après ce que j'ai lu je sais plus ou, Microsoft préparerait pour .NET 4.0 un langage F# (F comme functional)

http://research.microsoft.com/fsharp/fsharp.aspx

sur le papier ça a l'air de bien déboiter ce truc

 
Oué, en même temps c'est plus fun sur un clavier/Ecran

Ok
Ce genre de possibilités, c'est ce qui fait toute la différence entre un langage de script embarquable utile et un autre qui ne l'est pas. Rien de tel en effet pour pouvoir faire des batchs ou des tests.

quels sont les critères permettant de comparer divers langages ?
 
j'avais commencé à regarder du côté de groovy pour alléger un développement basé sur la JVM, mais KangOl m'a parlé de Pnuts après être venu sur ce thread.