Mais qu'est-ce que le projet whippet ? Whippet est un langage de script généraliste totalement écrit en C++. L'objectif de ce projet est de fournir un langage de script au code totalement portable (aucune ligne de code n'est spécifique à la plateforme d'exécution) et facilement extensible grâce à des interfaces prévues à cet effet.
On retrouve dans ce langage tous les aspects classiques d'un langage procédural "actuel" :
- structures if-else-endif ;
- Switch-case (l'élément suivant "case" peut être une variable...) ;
- Boucles for, while et until ;
- Ainsi que tout ce qui est indiqué sur la page du projet et qui n'a pas besoin d'être répété...
Le langage a prévu la possibilité de fonctionner dans la langue de l'utilisateur. Mais, chose particulière, la langue est fixée une bonne fois pour toutes à la compilation, évitant l'utilisation de variables d'environnement. En raison de la petite jeunesse du projet, seuls l'anglais et le français sont actuellement disponibles.
Afin de montrer les possibilités offertes par ce langage et, plus modestement, sa syntaxe, des scripts d'exemples sont fournis. Cependant, ces derniers ne sont pas encore exhaustifs et de plus amples démonstrations sont en préparations. Des pages de documentation devraient suivre. Le projet, publié en GPL version 3, compte sur des contributeurs du libre pour continuer à évoluer.
Aller plus loin
- Whippet home (45 clics)
- Hello world en Whippet (41 clics)
# On reste sur sa faim
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
Est-ce que c'est un langage pour le plaisir d'écrire un interprète, d'éducation, ou destiné à faire des logiciels en production ?
Un petit Hello World serait le bienvenue aussi, histoire d'avoir une idée de la syntaxe.
[^] # Re: On reste sur sa faim
Posté par Bruno Michel (site web personnel) . Évalué à 3.
methods_begin
proc myproc (a)
{
printout $a
}
methods_end
set string hello "Hello world!"
myproc ( $hello )
unset hello
[^] # Re: On reste sur sa faim
Posté par CrEv (site web personnel) . Évalué à 3.
la syntaxe est ... particulière ...
Déjà les commentaires derrière -- c'est pour le moins inhabituel
Ensuite j'ai bien du mal avec beaucoup d'aspects (en tout cas à la lecture des exemples) :
les mots clés 'methods_begin / methods_end'
Les sorties (derrière printout) assez étrange genre :
printout "compare: " $cmp \ngenre le \n qui traine tout seul, comme ça ... on sait pas trop ce que ça fait là
les assignations avec :=
En gros, je trouve le tout très (beaucoup trop en fait) inutilement verbeux, étrange, avec des mélanges de syntaxes inhabituels voir anciens.
Ce qui me donnerait envie de l'utiliser serait par exemple une syntaxe sympa, un petit plus quoi. Là ... ben j'ai pas trouvé.
Maintenant, il manque peut-être quelques informations genre pourquoi, dans quel but, comment, etc.
[^] # Re: On reste sur sa faim
Posté par peau chat . Évalué à 4.
la syntaxe est ... particulière ...
Déjà les commentaires derrière -- c'est pour le moins inhabituel
(...)
les assignations avec :=
Ces deux aspects là sont très habituels dans les langages SQL et dérivés (PL/pgSQL ; Transac-SQL ...).
[^] # Re: On reste sur sa faim
Posté par Maxime (site web personnel) . Évalué à 5.
Comme en Ada et VHDL.
>> les assignations avec :=
Comme en Pascal.
[^] # Re: On reste sur sa faim
Posté par CrEv (site web personnel) . Évalué à 4.
Mais reste que je trouve ça des plus étranges comme choix.
Et oui ça reste plutôt marginal lorsqu'on voit le nombre de langages utilisant // ou /**/ ou # (qui sont quand même les trois cas les plus courant) idem pour l'assignation en := surtout que les tests sont écrits en ==
En gros j'arrive pas du tout à comprendre cet ensemble de choix très étrange.
Mais oui, par certains côtés ça me ferait plus penser à du sql version script ...
[^] # Re: On reste sur sa faim
Posté par barmic . Évalué à -2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: On reste sur sa faim
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
[^] # Re: On reste sur sa faim
Posté par reno . Évalué à 2.
Pas que ce soit une critique d'ailleurs: je pense que je préfère Ada au C++..
# Pourquoi devrais-apprendre ce langage ?
Posté par JGO . Évalué à 6.
> un langage de script sans prétentions
Ce titre ne rassure pas. Cela veut dire que les concepteurs vont se limiter à un langage jouet ? je vais arriver à faire un petit programme, puis le jour où j'aurai besoin de le complexifier, je vais devoir faire faire des contournements douloureux des limitations, ou tout porter dans un autre langage ? Ça me rappelle le célèbre échange de messages entre RMS et le reste du monde à propos de Tcl : « a language for extensions should not be a mere "extension language". It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that! » — RMS, 23 septembre 1994 – http://www.vanderburg.org/OldPages/Tcl/war/0000.html
[^] # Re: Pourquoi devrais-apprendre ce langage ?
Posté par grid . Évalué à 1.
Pour le fun ? parce que ca fait rigolo sur un CV ?
[^] # Re: Pourquoi devrais-apprendre ce langage ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
Quand au fun, ça reste à voir. Si le langage n'apporte rien, il n'y a pas de fun.
Quels sont les algos qui s'expriment « mieux » dans son langage que dans un autre ? Quel est le charme de son langage ?
# Objectif
Posté par barmic . Évalué à 5.
« L'objectif de ce projet est de fournir un langage de script au code totalement portable (aucune ligne de code n'est spécifique à la plateforme d'exécution) et facilement extensible grâce à des interfaces prévues à cet effet. »
Par contre je me pose la question du positionnement de ce projet face à lua qui, il me semble, a un objectif analogue.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Objectif
Posté par Moonz . Évalué à 7.
[^] # Re: Objectif
Posté par barmic . Évalué à 2.
Ensuite je n'ai pas vu le langage mais s'il propose certaines abstractions comme pour les chemins alors il offre en standard des choses que tu ne trouve pas en lua ou perl (je crois).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Objectif
Posté par Moonz . Évalué à 1.
[^] # Re: Objectif
Posté par rhizome . Évalué à 5.
[^] # Re: Objectif
Posté par Kerro . Évalué à 5.
Par exemple PowerShell. En pratique, ce langage n'est porté nulle part. Pour plusieurs raisons dont l'une est la volonté de l'éditeur de ne pas le porter.
[^] # Re: Objectif
Posté par fantassin . Évalué à 1.
1/ code source en c++ strict
2/ pas de dépendances qui pourraient être absentes sur une plateforme
Voici le sens que le mot portable prenait ici
[^] # Re: Objectif
Posté par Barnabé . Évalué à 1.
«Whippet is a general purpose script engine written in pure C++. The code is portable and has no external dependencies.»
# explications...
Posté par fantassin . Évalué à 3.
Concernant les choix techniques, quelques explications:
1/ Les commentaires: le principal développeur est un très grand admirateur du VHDL, et en a assez des langages de scripts utilisant le # ou une inspiration C...
2/ Les assignations en := comme en camL ou Pascal: pourquoi pas...
3/ Les boucles un peu bizarres: pour changer un peu...
4/ methods_begin/methods_end: c'est assez bof
5/ le \n qui traine... les caractères d'échappement n'ont pas besoin d'être entre guillemets.
6/ printout et printerr: comprendre cerr et cout... De plus, la concaténation est implicite, pas besoin de points, de +... (mettre des guillemets quand même pour les espaces)
Voilà, les questions et remarques sont les bienvenues,
[^] # Re: explications...
Posté par Moonz . Évalué à 7.
> pourquoi pas...
> pour changer un peu...
Excuse-moi, mais ça fait un peu « changer pour changer », sans aucun réel argument derrière. Pour moi, un nouveau langage se doit d’apporter — relativement à l’existant — une amélioration sur au moins un de ces axes : expressivité, sécurité, performances — sinon c’est poubelle direct : si c’est pour juste changer = par :=, je peut très bien faire un coup de sed sur mes sources python, ce sera aussi efficace, et je bénéficierai de toute la librairie standard python, et de toutes les compétences des devs python pour la maintenance de l’interpréteur.
Concrètement, il apporte quoi relativement à Python ou Ruby, Whippet ? Encore une fois, remplacer "=" par ":=" et "#" par "--" n’est pas un apport.
[^] # Re: explications...
Posté par fantassin . Évalué à 3.
Au commencement, l'objectif était de pouvoir y ajouter facilement des fonctionnalités spécifiques pour plus tard étendre une application existante. Pour se faire, l'idée était de posséder un interpréteur (et une syntaxe) assurant le minimum vital.
Une usine à gaz comme Python n'est pas utile pour fournir une interface ligne de commande et de script comme dans les outils Xilinx (qui utilise Tcl je crois)
Petit, léger, ne comprenant pas grand chose d'inutile (pour l'instant), facile à intégrer à l'existant, facile à compiler en standalone...
Concernant la syntaxe, ceci est un choix, mais le fichier src/const.h permet de redéfinir facilement tous les mot-clefs et "balises" sans devoir modifier du code partout et obtenir une version très personnelle.
[^] # Re: explications...
Posté par Moonz . Évalué à 3.
1. Possibilité de modifier les mots clefs ("if" / "si") ? Pas très utile.
2. Possibilité de créer des APIs spécifiques ? Lua le fait.
3. Possibilité d’implémenter des paradigmes différents ? Là, ça peut être intéressant. Je peux facilement étendre le langage pour y mettre des closures ? Je peut en faire facilement un langage fonctionnel ?
[^] # Re: explications...
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
[^] # Re: explications...
Posté par rewind (Mastodon) . Évalué à 5.
# Oui, pète.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -1.
Sans prétention, peut-être. Sans odeur, ça reste à voir (ou à sentir).
-->[ ]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.