Swift est le nouveau langage de programmation d’Apple. Il a été rendu libre et open-source, sous licence Apache 2.0, le 3 décembre 2015. Nous allons voir à travers cet article comment l’installer et l’utiliser sur GNU/Linux. Vous n’avez pas besoin d’avoir de connaissance avancée de GNU/Linux, ni de machine avec GNU/Linux installée pour suivre ce tutoriel.
Sommaire
- Installation de Swift sur GNU/Linux
- Premier programme
- Ce qu’Apple a rendu open source
- Ce qui n’est pas (encore) disponible
- Swift Package Manager
- Références / Sources
Installation de Swift sur GNU/Linux
Si vous avez déjà Ubuntu 14.04 LTS ou Ubuntu 15.10, en machine physique ou virtuelle, vous pouvez simplement suivre les instructions sur le site swift.org pour télécharger et installer Swift pour Linux. Vous pouvez alors vous rendre directement à la section suivante.
La suite vous décrit les étapes pour installer simplement une machine virtuelle Ubuntu dotée du nouveau langage Swift.
Installation de VirtualBox
VirtualBox est un logiciel libre vous permettant de configurer et faire tourner des machines virtuelles. Si ce n’est déjà fait, installez-le en vous rendant à la page de téléchargement du site.
Installation de Vagrant
Vagrant est un logiciel en ligne de commande qui permet d’installer et configurer des machines virtuelles à l’aide de scripts. Rendez-vous à la page de téléchargement du site, téléchargez et lancez l’installeur du système d’exploitation de votre machine hôte.
À l’aide du script suivant, vous allez pouvoir télécharger et configurer votre machine virtuelle en une ligne de commande !
Créez un dossier vagrant-swift, puis créez dans ce dossier, un fichier nommé Vagrantfile contenant le code suivant :
Vagrant.configure(2) do |config|
config.vm.box = "ubuntu/trusty64"
config.vm.provision "shell", inline: <<-SHELL
sudo apt-get --assume-yes install clang
curl -O https://swift.org/builds/ubuntu1404/swift-2.2-SNAPSHOT-2015-12-01-b/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
tar zxf swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
echo "export PATH=/home/vagrant/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/bin:\"${PATH}\"" >> .profile
echo "Swift has successfully installed on Linux"
SHELL
endPour les utilisateurs Windows, il vous faudra un terminal qui permet d’exécuter des commandes Unix. Je vous recommande Git Bash de la suite Git for Windows. Durant l’installation, vous pouvez laisser toutes les options de configuration par défaut. Une fois installée, vous devez lancer Git Bash.
Ouvrez un terminal si ce n’est déjà fait (Git Bash si vous êtes sous Windows). Placez-vous dans le répertoire vagrant-swift et lancez la commande suivante :
$ vagrant upAllez boire une bière le temps que Vagrant procède aux étapes suivantes :
Téléchargement d’Ubuntu 14.04 LTS
Lancement de la machine virtuelle
Installation du compilateur clang
Téléchargement et décompression de Swift
Configuration de la variable PATH de l’utilisateur
Vous aurez peut-être des messages affichés en rouge, vous pouvez les ignorer. Si tout s’est déroulé correctement, le dernier message indique :
==> default: Swift has successfully installed on Linux
$ vagrant sshLa connexion établie, vous obtenez un prompt de ligne de commande :
vagrant@vagrant-ubuntu-trusty-64~$Vérifiez que Swift est bien installé en tapant :
vagrant@vagrant-ubuntu-trusty-64:~$ swift --version
Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c)
Target: x86_64-unknown-linux-gnuPremier programme
Live
Les développeurs iOS ou OS X le savent déjà grâce au playground d’Xcode, Swift est un langage pouvant être exécuté en live grâce au REPL (Read-Eval-Print-Loop).
Lancez la commande swift, un prompt apparaît, entrez alors votre première ligne de code Swift sur Linux !
vagrant@vagrant-ubuntu-trusty-64:~$ swift
Welcome to Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c). Type :help for assistance.
1> print("Hello, Swift!")
Hello, Swift!
2>Pour quitter votre session Swift REPL, entrez la commande :q.
Compiler un programme
Pour compiler un programme écrit en Swift, créez un fichier source, par exemple de la manière suivante :
$ cat > helloworld.swiftPuis rentrez cette unique ligne de code :
print("Hello World !")Appuyez une fois sur Entrée suivi de CTRL-D pour créer le fichier. Listez le répertoire courant pour vous assurer de la présence du fichier fraîchement créé en tapant la commande ls. Compilez maintenant votre programme en tapant :
$ swiftc helloworld.swiftSi vous listez le répertoire courant, vous verrez qu’un nouveau fichier exécutable nommé helloworld a été créé. Votre programme est prêt à être lancé, tapez :
$ ./helloworldVous devriez voir en sortie :
Hello World !
Ce qu’Apple a rendu open source
Seulement une partie de la technologie est disponible en open source pour le moment. Les composants sont :
- Compilateur Swift, sources et exécutables, débogueur, REPL. C’est le coeur du langage lui-même. Apple a rendu open les sources du programme swiftc, le même compilateur utilisé pour compiler les applications iOS et OS X.
- Bibliothèque standard Swift. Presque la même bibliothèque standard utilisée depuis la sortie de Swift, elle comprend la définition des collections, protocoles et autres fondamentaux. Si par curiosité, vous voulez voir comment est définie la classe (plus précisément la structure) String, rendez-vous sur le github ici.
- Bibliothèques Swift core. Elles font peau neuve aux bibliothèques existantes d’Apple écrites en Objective-C. Elles fournissent des fonctionnalités et des outils de haut niveau tels que ceux pour la communication web, l’interaction avec le système de fichiers, les calculs de date et heure.
- Swift Package Manager. C’est le maître de cérémonie de l’assemblage de chaque brique qui forme une application. Il va télécharger les dépendances, les compiler et les lier entre-elles pour créer des bibilothèques ou des exécutables.
- Mais encore… Si vous parcourez la page Github d’Apple, vous trouverez d’autres composants tels qu’une encapsulation de libdispatch (Grand Central Dispatch), des informations sur Swift 3.0, ou même un parseur du langage Markdown…
Ce qui n’est pas (encore) disponible
Il manque à l’appel la plupart des frameworks qui rendent les applications iOS et OS X aussi belles. Pour n’en citer que quelques-uns : AppKit, UIKit, Core Graphics, Core Animation, AVFoundation…
Vous ne trouverez pas non plus l’environnement de développement intégré Xcode.
Mais ce qu’Apple a rendu open source est plutôt significatif. En effet, le fait que les bibliothèques Swift Core ne reposent plus sur l’environnement d’exécution Objective-C montre qu’Apple est en train de créer les fondements de Swift pour, à long terme, remplacer Objective-C. De plus, le fait que Swift soit cross-platform suggère qu’Apple espère voir les développeurs l’utiliser pour le développement d’applications Linux entre autres. Si ce n’est pour des applications GUI, au moins pour des applications serveurs.
Swift Package Manager
Voyons en pratique l’utilisation du package manager sur un exemple simple, un petit jeu de « pierre, feuille, ciseaux ». Créez un dossier helloswift puis un dossier sources à l’intérieur du premier en exécutant les commandes suivantes :
$ mkdir helloswift
$ cd helloswift
$ mkdir sources
$ cd sourcesCréez ensuite un fichier nommé main.swift, (le nom main est important pour la suite), dans le répertoire sources en exécutant :
$ cat > main.swift
Copiez le programme suivant :
import Foundation
import Glibc
let player = ["pierre", "feuille", "ciseaux"]
srandom(UInt32(NSDate().timeIntervalSince1970))
for count in 1...3 {
print(count)
sleep(1)
}
print(player[random() % player.count]);Tapez Entrée puis CTRL-D.
Vous pouvez d’ores et déjà exécuter votre programme avec la commande :
$ swift main.swift Génial ! Il faut que j’en parle aux copains !
Arf… il n’auront pas la commande swift…
C’est ici que le Swift Package Manager entre en jeu ! Grâce à lui, vous allez pouvoir distribuer un exécutable de ce formidable programme. Créez un fichier Package.swift dans le dossier parent (helloswift) :
$ cd ..
$ cat > Package.swiftCopiez ceci dedans puis tapez Entrée et enfin CTRL-D :
import PackageDescription
let package = Package(
name: "Chifoumi"
)Lancez la commande de build :
$ swift buildSwift détecte automatiquement le point d’entrée du programme car nous avons nommé notre fichier main.swift. Si vous renommez ce fichier, vous aurez des erreurs de compilation. En revanche le changement de nom du dossier sources n’affecte pas la compilation mais l’exécutable créé portera le nom du dossier et non le nom donné dans le fichier Package.swift. Si la compilation réussit, le package manager crée un dossier .build contenant un dossier debug dans lequel se trouve l’exécutable Chifoumi. Vous pouvez alors le distribuer et quiconque ayant une machine Linux pourra l’exécuter en tapant la commande suivante dans le répertoire où se trouve l’exécutable :
$ cd .build/debug/
$ ./ChifoumiLe Swift package manager possède évidemment beaucoup de fonctionnalités que nous n’avons pas explorées. Un guide d’utilisation plus avancée fera peut-être l’objet d’un nouvel article, qui sait ?
Stay tuned !
Références / Sources
- Site officiel
- GitHub
- http://www.raywenderlich.com/122189/introduction-to-open-source-swift-on-linux
- https://www.twilio.com/blog/2015/12/getting-started-with-swift-on-linux.html
- Page sur Wikipedia (en)
Aller plus loin
- Article original sur le blog d'Itelios (616 clics)
- Site officiel de Swift (555 clics)
- Annonce de Swift sur LinuxFr.org (242 clics)
# Pourquoi ?
Posté par karchnu . Évalué à 10.
Pourquoi voudrait-on de cet outil ? N'y a-t-il pas déjà des dizaines d'autres langages qui sont disponibles ayant les mêmes fonctionnalités (voire plus) sur nos systèmes favoris ? Quel avantage j'aurais à me mettre à Swift ? Pourquoi ne pas ajouter quelques fonctionnalités à des langages déjà existants plutôt que de partir sur Swift ? Ne serait-ce pas une hype passagère ?
[^] # Re: Pourquoi ?
Posté par debovitch . Évalué à -2.
Cet article a été dispensé de ses images originales :
Il faut également se mettre du côté du développeur iOS qui connaît déjà ce langage, et qui a envie de développer sur d'autres plateformes…
[^] # Re: Pourquoi ?
Posté par macadoum . Évalué à 10.
Merci l'image de propagande …
[^] # Re: Pourquoi ?
Posté par Nim65s . Évalué à 10.
Tiens, il manque Rust & Go
Just Sayin’
[^] # Re: Pourquoi ?
Posté par karchnu . Évalué à 8.
Ce schéma n'apporte aucune information, si ce n'est un avis totalement subjectif et incomplet.
[^] # Re: Pourquoi ?
Posté par flan (site web personnel) . Évalué à 7.
Si, il apporte la cible visée de façon très explicite : ils veulent concilier performances et simplicité d'écriture, donc plus ou moins le même créneau que Go.
Ça montre clairement que ce n'est pas un langage de script lent mais super rapide à écrire, ou un langage super performant mais dont la simplicité aurait été sacrifiée. Je trouve que c'est plutôt un bon résumé (et pas besoin de mettre tous les langages de la terre, ce n'est pas une comparaison avec eux).
[^] # Re: Pourquoi ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Pour un peu moins de doigt mouillé, on peut prendre le langage shootout avec la comparaison de la taille de code vs la vitesse dans des exemples standardisés :
source : http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html issue de https://benchmarksgame.alioth.debian.org/
"La première sécurité est la liberté"
[^] # Re: Pourquoi ?
Posté par dromadaire35 . Évalué à 10.
OCaml presque idéal ? Ça me va :-)
[^] # Re: Pourquoi ?
Posté par karteum59 . Évalué à 6. Dernière modification le 09 mars 2016 à 14:09.
Mouais, admettons…
Cela dit il y a un troisième critère qui n'est pas mesuré et qu'il faudrait mettre sur un 3ème axe : la courbe d'apprentissage du langage ! (par exemple, Haskell (que je ne connais pas) a l'air fabuleux sur le papier mais le peu que j'ai regardé m'a fait peur car je me demande combien de temps (ou quel bagage théorique) il faut passer dessus avant d'arriver à être un minimum productif). Je pense que Go est clairement le prochain sur ma to-do list (sauf si Swift arrive à me convaincre :)
[^] # Re: Pourquoi ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Je connais peu Haskell et beaucoup Oaml, on retrouve les même concept. Le principale problème de ces langages est qu'ils sont "vendu" par des matheux bac+12 de 120 de QI. Donc, ils oublient quelques bases, comme des messages d'erreurs lisibles, obligatoire pour le débutant (petit souvenir de gcc 2.95 et de ses messages lunaires.). Ils aiment bien commencer par les gros mots : comme monade, type algébrique, closures, ou bien currying. Des trucs bien inutiles pour commencer.
"La première sécurité est la liberté"
[^] # Re: Pourquoi ?
Posté par kantien . Évalué à 5.
Tu es un peu dur, même si tu n'as pas complètement tort : on trouve des personnes qui présentent ainsi le langage à des non initiés, ce qui les fait fuir inéluctablement.
Pour les messages d'erreurs, je viens de faire dans mon toplevel :
et le
"1"est souligné pour indiquer qu'elle est l'expression qui n'a pas de le bon type.Pour ce qui est de l'apprentissage, je conseille le livre de Sylvain Cochon et Jean-Christophe Filliâtre Apprendre à programmer en OCaml. Ils sont enseignants-chercheurs, et enseigne la programmation OCaml au niveau licence, donc sans tous les gros mots. ;-)
Le livre présente progressivement les concepts du langage et débute d'ailleurs par des traits purement impératifs comme les boucle for, les tableaux, les boucles while pour n'aborder qu'ensuite les spécificités du paradigme fonctionnel.
Les deux auteurs ont d'ailleurs une approche intéressante du paradigme fonctionnel qui consiste essentiellement dans la persistance des données. Ils ont, par exemple, publié ensemble un article A Persistent Union-Find Data Structure où ils exposent leur implémentation de l'algorithme union-find en utilisant des traits impératifs du langage, bien que la structure obtenue soit persistante. Là où un langage fonctionnelle pure, comme Haskell, aurait recours à des monades. Et dans leur livre il y a tout un chapitre, par exemple, où ils reprennent le concept de tableaux persistants, dont le code suit, en l'expliquant pas à pas :
Les opérations
setetgetsont en temps constant tant que l'on n'utilise pas le côté persistant, mais on paye un léger prix lorsque l'on veut l'utiliser (il faut défaire lespatchde la version courante pour revenir à la version que l'on souhaite manipuler, c'est le rôle de la fonctionreroot).Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi ?
Posté par karteum59 . Évalué à 7. Dernière modification le 09 mars 2016 à 18:24.
Après, en ce qui me concerne, quand je dois choisir un langage je me pose aussi (entre autres) les questions suivantes :
Je n'ai pas l'impression que OCaml satisfasse ces deux critères (mais corrigez-moi au besoin).
[^] # Re: Pourquoi ?
Posté par kantien . Évalué à 1. Dernière modification le 09 mars 2016 à 19:15.
Pour le premier point OCaml le fait :
Pour le second (QT5) je ne sais pas. Je n'ai rien trouvé dans les dépôts opam (le gestionnaire de paquets haute performance OCaml) mais tout ne s'y trouve pas.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi ?
Posté par kantien . Évalué à 2.
Autre point que je n'ai pas mentionné, c'est la bibliothèque standard. Celle de base, fournie par INRIA, est souvent jugée limitée : elle est surtout développée pour le compilateur. Néanmoins, la société Jane Street a développé la bibliothèque core pour remédier à ce problème. C'est celle qui est utilisée dans les exemples du livre Real World OCaml.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi ?
Posté par Michaël (site web personnel) . Évalué à 7.
Honnêtement je trouve que c'est un reproche aussi fréquent qu'immérité. Est-ce qu'on fait ce reproche à C dont la bibliothèque standard est encore plus légère? Où à C++ qui pendant des années n'avait pratiquement pas de bibliothèque standard (pre-STL)? Alors bien-sûr, d'autres langages ont des approches différentes, comme Java qui propose une bibliothèque de base très étoffée.
Des utilisateurs industriels qui développent toute une infrastructure en OCaml ont évidemment des besoins qui les poussent à implémenter une alternative à la bibliothèque standard – mais c'est le cas de beaucoup de gros projets logiciels de toute façon – par exemple GTK+ a sa glibc, originellement écrite pour gimp, et divers logiciels métiers sur lesquels j'ai travaillé ont aussi leur bibliothèque standard maison.
Je trouve que c'est un faux problème maintenant que opam est disponible et fonctionne bien, on n'a quasiment aucun intérêt à avoir une bibliothèque de base tout-équipée – qui de toutes façons sera dans la plupart des cas d'application concrète trop générale, ou trop ceci ou pas assez cela – puisqu'on peut rassembler les composants dont on a besoin en quelques minutes.
Aussi, pour les mécanismes de mise à jour, correction de bogues, etc. il est plus intéressant d'avoir une multitude de petits projets qu'un gros monolithe mis à jour une fois tous les six mois, au prix d'interminables discussions pour changer une virgule ici ou là.
Pour terminer je réponds déjà à ceux qui grognent “oui, mais à quoi sert de réinventer la roue? je veux une bibliothèque standard avec totu dedans” en se réclamant d'un pragmatisme, souvent auto-déclaré et illusoire. Dans la pratique, il n'y a pas de recette magique: les solutions générales sont invariablement inadaptées aux problèmes particuliers! (Truisme du jour.) C'est pour ça que quand on étudie les math et l'info on étudie les preuves et les algorithmes: pour pouvoir adapter les théorèmes et les algorithmes aux cas particuliers que l'on rencontre et où l'énoncé général ne s'applique pas.
[^] # Re: Pourquoi ?
Posté par kantien . Évalué à 5.
Je suis bien d'accord avec toi, mais je l'ai souvent entendu c'est pour cela que je l'ai précisé. Et effectivement, elle est bien plus fournie que la bibliothèque standard C. Mais ceux qui ont connu Python, par exemple, doivent croire que tout langage vient avec une bibliothèque standard aussi fournie.
Comme tu l'as dit, depuis l'arrivée de
opamon peut toujours trouver une bibliothèque qui correspond au besoin. Au fond le dépôtopamest la bibliothèque standard. ;-)Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Il manque quand même une vrai library graphique. Le port de gtk ressemble à un hack et n'est pas vraiment maintenu. Un langage moderne sans GUI c'est dommage.
Si on pouvait faire un serveur web correct comme en go, le problème serait bien plus limité.
"La première sécurité est la liberté"
[^] # Re: Pourquoi ?
Posté par Michaël (site web personnel) . Évalué à 2.
La bibliothèque labltk est largement sous-estimée et j'ai commencé à travailler (trèèès lentement) pour ajouter les widgets Tk plus modernes qui manquent – l'idée serait d'avoir une bibliothèque lablttk. Les plus gros défaut de Tk est probablement de ne pas avoir de widgets pouvant afficher une page Html ou jouer une vidéo mais pour toutes les autres applications, elle fonctionne bien et test très facile à programmer.
Qu'est-ce que tu entends par serveur HTML correct? Il y a 36 000 bibliothèques pour faire ça, à défaut d'apprendre Eliom j'ai commencé à travailler avec webmachine, c'est très bien.
[^] # Re: Pourquoi ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6. Dernière modification le 10 mars 2016 à 10:08.
A moins qu'elle est beaucoup changé, elle était très très moche et ne disposait pas de widget digne de ce nom (tableau "lazy", arbre, canvas moderne).
En général, quand il y a en 50, c'est que aucune fonctionne correctement : trop lent, ne passe pas à l'échelle, ou propose des latences dû au gc trop importante, ou encore sont trop pauvre. J'avais espoir dans oscigen, mais je ne comprends rien à leur super tuto. De plus, il n'utilise pas du ocaml standard.
Je vais regarder webmachine, on ne sait jamais.
"La première sécurité est la liberté"
[^] # Re: Pourquoi ?
Posté par kantien . Évalué à 3.
Si c'est juste pour avoir un serveur web, il y a ocsigen server. Après les tutos sont surtout là si tu veux faire une webapp en full-OCaml avec le framework eliom qui permet de coder les parties clients et serveurs en même temps. Et 200 lignes de code pour faire une appli simple de dessin collaboratif, c'est pas mal je trouve.
Qu'entends-tu par « il n'utilise pas du OCaml standard » ? Est-ce l'usage de fichier
.eliom? Cela est du à la nécessité de compiler différemment les code clients et serveurs que l'on met dans le fichier entre les balises[%%client],[%%server]ou[%%shared], mais entre ces balises c'est bien du OCaml standard.Sinon il y a aussi cohttp développé par l'équipe de mirage.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Tu parles de ça : https://github.com/inhabitedtype/ocaml-webmachine ?
Un truc en version 0.3 qui existe depuis aout 2015 ? Il a des utilisateurs ?
"La première sécurité est la liberté"
[^] # Re: Pourquoi ?
Posté par Michaël (site web personnel) . Évalué à 2.
Oui je parle de ça. Il est utilisé par l'entreprise qui le développe (je suppose) et j'ai commencé à expérimenter avec. Il s'agit d'un port d'un projet Erlang, il est donc plus mature que ce que son numéro de version peut laisser supposer.
[^] # Re: Pourquoi ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Tu sais aussi que c'est le même genre d'erreur si il y a redefinition de type, ce qui donne :
Error: This expression has type mytype_t but an expression was expected of type mytypet_
Je crois qu'ils sont en train de travailler dessus, ce qui manque c'est les adresses dans les fichiers du pourquoi de l'erreur, en gros, les 2 définitions qui entre en conflit.
Pour des pures débutant, je ne suis pas sur que map et fold_left fasse si peur. Gérer correctement une boucle peut être bien plus compliqué que l'on peut le croire (erreur d'off by one). Et une fois que l'on a gouter au filtrage de type, on a plus besoin du "if" :)
"La première sécurité est la liberté"
[^] # Re: Pourquoi ?
Posté par kantien . Évalué à 4.
Effectivement, à ce niveau tu as raison. Il me semble aussi qu'ils travaillent dessus, ce qui est d'ailleurs plus une question de temps à consacrer au sujet que de difficultés. À mon avis, si ce n'est pas encore présent c'est que ceux qui s'occupent du compilateur bossent tous sur Emacs et que leurs extensions résolvent déjà ce problème, donc de leur seul point de vue il n'existait pas.
Le
ifpeut bien servir de temps en temps (test d'égalité physique ou structurelle) mais assurément le pattern matching est le cœur d'un code OCaml. Mais l'ouvrage que je citais amène bien évidemment tous ces concepts (pour preuve l'exemple de code que j'ai cité) mais dans une approche progressive que je trouve bien faite sur le plan pédagogique. Et l'on n'y trouve pas tous les gros mots que tu as cités : monades, type algébrique, clôture, currification… ou du moins pas d'entrée de jeu. Il n'y est jamais question de monade (c'est indispensable en Haskell pour les IO, mais pas en OCaml) ni de clôture (il me semble), et ils parlent un peu de types algébriques et de currification (c'est indispensable) mais sans rentrer dans le détail : c'est inutile, il vaut mieux apprendre par l'exemple. Mais l'on aborde des techniques évoluées du langage comme la fonctorisation.Pour revenir sur la non-nécessité des monades en OCaml, qui reste pour moi le concept le plus abstrait et sans doute le plus dur à comprendre dans ta liste, je vais revenir sur le code que j'avais cité en exemple. Au fond ce qu'ils codent pour avoir des tableaux persistants c'est un système de contrôle de version sur des tableaux : faire un
setc'est faire un commit sur la structure et la fonctionreroota pour rôle de se rebaser sur le tableau sur lequel on veut opérer : on modifie le graphe desdiffjusqu'à ce que notre tableau soit à la base et un « véritable » tableau. Et pour faire cela, ils manipulent des pointeurs ce qui est impossible en fonctionnel pur à la Haskell. Néanmoins pour l'utilisateur d'une telle structure de données, on lui présentera cette interface dans le fichier.mli:La fonction
rerootfait partie de la machinerie interne (du point de vue du mathématicien, c'est un lemme qui n'a pas besoin d'être connu de l'utilisateur), la représentation concrète du type lui est cachée (il ne peut donc pas manipuler les pointeurs) et pour lui tout ce passe comme si c'était du fonctionnel. C'est pour cela que les auteurs aiment bien définir ainsi une des caractéristiques du paradigme fonctionnel :Et effectivement la structure des tableaux persistants fonctionne avec des effets de bord (les fonctions
setetreroot) mais cela c'est en interne et l'utilisateur ne l'observe pas : pour lui la structure est persistante.Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi ?
Posté par zaurus (site web personnel) . Évalué à 2.
Et encore, le 120 de QI est une borne basse.
[^] # Re: Pourquoi ?
Posté par reno . Évalué à 3.
Surtout il me parait totalement faux: Javascript moins performant que Python ou Ruby??
Avec les sommes investies dans Javascript, ça m'étonnerait..
[^] # Re: Pourquoi ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Oui, c'est complètement faux si on regarde le shootout : https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=v8&lang2=python3
"La première sécurité est la liberté"
[^] # Re: Pourquoi ?
Posté par Albert_ . Évalué à 2.
Si j'en crois le code on compare un truc hyperoptimise avec un truc generic sans se servir de option optimisation tel que numpy (voir bientot les type hint).
Ouhais c'est super comme comparaison… Savoir que Cpython est lent par defaut pour du calcul numerique c'est une super nouvelle…
[^] # Re: Pourquoi ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Il y a plusieurs version de python utilisé. Le shootout propose différent type d'algo, et pas seulement du calcul numérique.
Avant de critiquer, je me demande si tu as simplement été voir le benchmark !
"La première sécurité est la liberté"
[^] # Re: Pourquoi ?
Posté par Albert_ . Évalué à 1.
Je suis alle voir le premier n-body et vu la non optimisation total du python je pense que malheureusement comme tout benchmark celui la ne veux rien dire de plus que ce que son auteur veux montrer.
[^] # Re: Pourquoi ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Tu es pénible. Vraiment. C'est marqué de long en large sur le site du benchmark en question. Les codes sont fournis par les utilisateurs du langage. Si tu penses faire mieux fait une proposition.
Et j'imagine que tu n'as sans doute pas compris que l'algorithme est fixe.
"La première sécurité est la liberté"
[^] # Re: Pourquoi ?
Posté par jseb . Évalué à 1.
Lua moins performant que Python, Ruby et Javascript ?!
Il manque au minimum quelques explications sur ce graphique.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Pourquoi ?
Posté par Misc (site web personnel) . Évalué à 4.
On parle d'une présentation Apple. Le but est pas d'être précis mais de tracer des grands traits qui sont repris par les fans.
C'est aussi à cause de ce genre de présentation que les maceux se font vanner à longueur de temps, mais comme Apple fait bien les choses, ça renforce le message principal (à savoir qu'utiliser un mac permet d'être différent).
[^] # Re: Pourquoi ?
Posté par TheGuit (site web personnel) . Évalué à 7.
La question de la pertinence d'un outil. C'est très philosophique tout ça. Pourquoi avoir un inventé le Go, le Rust ou que sais-je encore. N'avais t'on pas assez de langage avec Cobol, ASM et C/C++. C'est un nouveau langage, il arrive forcément avec des avantages des inconvénients. Le fait qu'ils soit amené a devenir le langage de prédilection pour l'univers Apple va forcément créer un grand nombre de développeur qui seront à l'aise avec celui ci et qui voudront un jour ou l'autre surement faire des choses utilisable dans d'autre environnement que MacOS/iOS.
Je crois que le libre nous a appris que la multiplicité des solutions et la saine concurrence est une bonne choses. Donc tant mieux que cela soit porté sur Linux et soutenu par Apple et IBM. Laissons au temps nous dire si c'était intéressant ou pas.
[^] # Re: Pourquoi ?
Posté par karteum59 . Évalué à 8.
Bof, l'existence de Mono a t-elle entrainé l'usage massif de c# sous d'autres environnements que Microsoft ? (peut-être que la comparaison est foireuse, mais c'est la première réflexion que m'amène ta remarque)
(cela dit pas de méprise: je suis très content que Swift existe et soit désormais ouvert et fonctionne sous Linux ! :)
[^] # Re: Pourquoi ?
Posté par Nico7as . Évalué à 8.
Parce qu'un très grand nombre d'applications iOS repose sur une relation Client-Server, Swift pour Linux permet de coder l'application cliente et l'application serveur avec le même langage : gain de cohérence, et gain de temps.
De plus, Swift est très proche d'un langage de script, permettant de coder efficacement, d'en faciliter la maintenance, et sa compilation efficace permet d'atteindre un niveau de performance semblables aux langages traditionnellement plus proche de la machine comme C ou C++.
C'est en tout cas l'argumentaire d'Apple, et d'après les forums, de nombreux développeurs sont enthousiastes et parlent d'une belle évolution par rapport à Objective-C (qui était déjà apprécié par les dev. orienté Apple)
[^] # Re: Pourquoi ?
Posté par CrEv (site web personnel) . Évalué à 0.
Pourquoi pas imaginer l'utiliser pour faire du développement cross platform par exemple ?
Exactement comme chaque langage en son temps.
[^] # Re: Pourquoi ?
Posté par Philippe Martin . Évalué à 3.
De ma toute petite expérience de développement sous iOS en objC et Swift, je pense qu'ils essaient de passer à un langage plus haut niveau que objC tout en gardant la compatibilité avec ce dernier, pour simplifier la maintenance de Cocoa : il ont créé une surcouche Swift au dessus de Cocoa objC pour pouvoir faire des appels en Swift depuis ton programme, tout en laissant la possibilité de faire aussi des appels en objC. Je crois qu'ils seraient bien embêtés s'ils devaient réécrire tout le framework en Go ou Java, quand on voit que la surcouche dont je parle n'est pas encore bien terminée.
Pour donner une image très très générique, on retomberait sur l'utilisation de l"extern C" dans du C++.
Mais c'est juste mes 0,00002€, si MrPomme voulait bien nous expliquer, ce serait sûrement plus clair …
[^] # Re: Pourquoi ?
Posté par luxcem . Évalué à 1.
Il y avait eu des discussions intéressantes sur : https://linuxfr.org/users/spack/journaux/apple-annonce-swift-son-nouveau-langage-de-programmation
# Heu
Posté par MTux . Évalué à 0.
Heu… le seul moyent d'installer Swift c'est Vagrant ? C'est à dire télécharger une VM ?
Il n'y a pas de procédure à l'ancienne du genre récupération des sources, compilation, installation ?
[^] # Re: Heu
Posté par debovitch . Évalué à 4.
La première ligne de l'article indique :
[^] # Re: Heu
Posté par flan (site web personnel) . Évalué à 4.
J'ai l'impression que ce qui est fait dans la VM vagrant y ressemble pas mal :
[^] # Re: Heu
Posté par debovitch . Évalué à 2.
Cet article est destiné au grand public, pas forcément linuxien :
D'où les deux méthodes proposées…
[^] # Re: Heu
Posté par luxcem . Évalué à 1.
D’ailleurs, c’est étrange de proposer de télécharger vagrant depuis le site et sans passer par les dépots. On a inventé les gestionnaires de paquets depuis non ?
[^] # Re: Heu
Posté par debovitch . Évalué à -1.
L'article s'adresse à tous les publics, pas forcément linuxiens, le lecteur peut être sous Mac ou Windows.
# C'est la mode de porter sur linux
Posté par Gauthier Monserand (site web personnel) . Évalué à 8. Dernière modification le 09 mars 2016 à 09:48.
Après swift ce sera bientôt mssql server (?!) qui va tourner sur linux.
Le portage d'applicatifs sur linux par des éditeurs qui ont leur propre OS est quand même un tournant important qui se confirme depuis quelque temps. C'est pour séduire les développeurs ou juste pour pouvoir être lancé dans docker ? :)
[^] # Re: C'est la mode de porter sur linux
Posté par dantes94 . Évalué à 2.
SI par mssql server tu entend SQL server de microsoft alors oui le portage a été annoncé il y a peu ;)
https://www.microsoft.com/en-us/server-cloud/sql-server-on-linux.aspx
Quant aux raisons, il est possible que le but soit de séduire les dev pour s'assurer que les outils proposés dureront dans le temps face à la concurrence, et ce même en cas de changement d'environnement de travail.
[^] # Re: C'est la mode de porter sur linux
Posté par Wawet76 . Évalué à 2.
Là c'est un peu plus que du portage sous Linux comme SQL Server. C'est une diffusion sous une licence libre. Faut plutôt comparer à .Net Core qui est dispo en MIT, ou à l'ouverture de la JVM côté Java.
[^] # Re: C'est la mode de porter sur linux
Posté par barmic . Évalué à 6.
Si je ne m'abuse la JVM n'a jamais était ouverte, c'est une ré-implémentation (OpenJDK) qui a finie par être utilisée comme référence (mais la JVM de sun est toujours fermé je crois, tout comme jrockit).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est la mode de porter sur linux
Posté par djano . Évalué à 6.
Tu te trompes: hotspot a bien été libérée par Sun, de même que toutes les classes du JDK.
OracleJDK c'est OpenJDK + le plugin Java proprio pour les navigateurs (tout troué: les failles Java, c'est lui en fait! - remplacé par IcedTea en libre) + des extensions pour les fontes ou des choses graphiques (je crois) + les extensions commerciales maintenant (mission control)
# Pourquoi pas ? Parce queeeeeee !
Posté par gyom gyom . Évalué à 0.
Effectivement, plus y'a de codes libérés mieux c'est. Un autre langage, pourquoi pas…
En revanche, ne nous y trompons pas : si M$ et Apple libèrent des trucs, c'est par ce qu'ils ont compris qu'ils peuvent en tirer de l'argent…
Notons particulièrement, qu'ils ne libèrent que des bribes inutilisables sans une partie non-libre et qui-ne-tourne-que-sous-leur-OS-proprio…
De ce fait :
Non les devs Apple, qui développent des belles-applis-bien-graphiques, où il compte plus de faire joli que fonctionnel, n'iront pas développer sous linux (ou autre OS libre) avec un ersatz de leur langage chéri ou, s'ils osent essyer, seront tellement déçu qu'ils en reviendront en disant que linux-c'est-de-la-merde, sans comprendre que ce-qui-est-de-la-merde c'est le code d'Apple… Il suffit de voir ce qui s'est passé avec les devs windows, qui ne sont pas venus sous linux pour développer avec un Mono à moitié fonctionnel.
Pour ce qui est des devs linux (ou autre, j'insiste), ils essayeront ptet le language, s'inspireront ptet des concepts intéressants pour leurs propres applis/langages, mais quand ils verront qu'ils ne peuvent pas faire une appli complète avec GUI, ou alors uniquement à destination des Mackeux, ou alors pour faire un démon, mais qui nécessitera à l'utilisateur d'installer des milliers de packages de langage et de libs supplémentaires inutiles, ils reviendront à leur langage complet d'origine…
Je ne vois que deux utilités à cette "libération" (très partielle) :
- le GreenWashing pour les gros trust amerlocks (comme quand ELeclerc vend du "Bio" avec un label bien à lui qui respecte en rien la nature mais lui permet de vendre son produit 3* plus cher).
- la possibilité pour eux ou leur devs de faire tourner les parties "serveur" de leurs applis en s'appuyant sur des fermes de calculateurs reposant sur un (autre) OS simple, stable, sécurisé et efficace afin d'offrir un service plus fiable et à plus de gens. Et aussi, du coup de profiter de tous les outils/libs disponibles dans cette écosystème (par exemple la conversion en divers formats - odf, odp, ods, doc, xls, pdf, ogg, ogv, avi, mp4, etc. - gratuite et efficace…)
Donc oui, eux y gagnent (en image et en perf), la communauté, c'est moins sûr…
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par CrEv (site web personnel) . Évalué à 9.
S'ils ont compris qu'ils pouvaient tirer des revenus en portant des outils sous linux c'est plutôt une bonne nouvelle, non ?
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par dantes94 . Évalué à 1.
"si M$ et Apple libèrent des trucs, c'est par ce qu'ils ont compris qu'ils peuvent en tirer de l'argent…"
C'est mal en soi ?
"Notons particulièrement qu'ils ne libèrent que des bribes inutilisables sans une partie non libre et qui-ne-tourne-que-sous-leur-OS-proprio…"
Je n'ai peut-être pas tout saisi, je débute en programmation, mais j'ai bien l'impression que Swift peut être compilé et exécuté sous Linux, donc en laquelle il serait inutilisable ?
"mais quand ils verront qu'ils ne peuvent pas faire une appli complète avec GUI"
L'un des intérêts de l'open source ne serait pas justement de pouvoir pallier ce problème ?
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par DerekSagan . Évalué à 7.
Ce me semble qu'il permet de faire des GUI sur iOS et OSX mais pas sous Linux. Sous Linux en l'état il permet juste de faire le composant serveur dans le même langage que le client qui est lui scotché sur une desdites plateformes proprio.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 1.
Cela dit la plupart des langages, à ma connaissance, ne disposent pas d'une bibliothèque GUI qui leur est propre. À partir du moment où on peut appeler du code C sans trop de difficulté, ça paraît envisageable d'avoir des bindings pour, par exemple, Gtk+ (Qt vu que c'est du C++ c'est déjà une autre paire de manches). La question après c'est de savoir s'il y aura suffisamment d'utilisateurs/développeurs sous systèmes libres pour qu'il soit possible de trouver facilement des bindings pour la bibliothèque que tu veux utiliser.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par barmic . Évalué à 3.
Je ne crois pas que ce soit le fait que l'un soit en C et l'autre en C++ qui ai eu un impact sur le nombre de binding de l'un et de l'autre, mais plutôt toute la tambouille autour de GObject qui permet de générer les bindings dans chaque langage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par DerekSagan . Évalué à 3. Dernière modification le 11 mars 2016 à 18:28.
oui faut bosser (beaucoup)
sauf que l'intérêt de swift sur les plateformes apple, c'est core graphics et xcode, et que comme par hasard ils ne sont pas portés sous linux
core graphics c'est la lib gui (le toolkit si tu préfères le vocabulaire gtk) et xcode c'est l'ide, sans ces deux éléments on peut toujours faire, mais à la main et c'est vachement plus long (en langage de manager: la productivité laisse vraiment à désirer)
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par flan (site web personnel) . Évalué à 2.
A priori, CLion (un IDE utilisable sous Linux) va permettre d'utiliser du Swift. C'est toujours ça de pris !
J'attends de voir un peu ce qui se passe, mais j'envisage de tester le Swift (j'hésite encore avec le Go) dans quelques mois pour un projet (un serveur particulier) maintenant que ça fonctionne sous Linux.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par DerekSagan . Évalué à 2.
juste lol
après tu peux utiliser Swift sous Linux pour un serveur, effectivement, mais c'est bien à ça qu'Apple entend au moins pour le moment le limiter
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par flan (site web personnel) . Évalué à 2.
Apparemment, le plugin Swift est dispo : https://blog.jetbrains.com/clion/2015/12/clion-1-5-eap-opens-dive-deep-into-directories-control-swift-and-more/
Et même si CLion n'est ni libre, ni gratuit, ça ne l'empêche pas d'être utilisable. Peut-être que ça suffit pour toi à le disqualifier d'office, mais manifestement ça n'arrête pas tout le monde (comme les différents outils de Jetbrains de façon générale).
Certes il n'y a pas d'outils de création de GUI (c'est effectivement dommage et c'est général aux outils Jetbrains, à ma connaissance), mais je ne pense pas que ça soit tellement éliminatoire : pas mal de langages n'ont pas de tels outils (ou n'en ont eu que tardivement) et ont quand même eu du succès.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par barmic . Évalué à 3.
Je connais beaucoup de développeurs web qui n'utilisent pas d'éditeur HTML graphiques. Ça ne dois pas arrêter tout le monde. AMHA avoir une boucle de feedback rapide est suffisant pour beaucoup de gens (et pas mal préfèrent du code et une boucle de feedback rapide que d'apprendre une nouvelle UI).
Une fois cela dis, je ne sais pas ce qu'il en ai pour swift (mais go est-il bien différent à ce niveau là ?).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par DerekSagan . Évalué à 2. Dernière modification le 17 mars 2016 à 15:45.
Moi aussi.
Mais je ne parle pas d'interface web mais de GUI.
Tu sais le truc que tu lances hors du navigateur sur ton poste de travail et qui fait plein de fenêtre.
Ou, plus à la mode, l'application native et réactive que t'as sur ton téléphone même quand t'as pas de réseau et qui est plus cool que le site web (même responsive) des gens qui l'ont codée.
D'ailleurs ça m'étonnerait que la majorité des developpements Swift à ce jour (sur iOS et OS X donc) soient des applis web…
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par barmic . Évalué à 3.
Ça n'a rien avoir. Beaucoup de gens font des UI très bonnes avec du HTML/CSS sans avoir besoin de designer et ce pour desktop comme pour périphériques mobiles. Je ne vois pas pourquoi ça ne serait pas le cas pour des bibliothèques d'UI natives. Sincèrement pour faire du QML tu n'a pas besoin de designer et le code généré par GtkGlade/GtkBuilder est affreux (en lisibilité, je ne sais pas jugé de la performance du truc).
À titre personnel, je préfère très largement utiliser un DSL (comme QML) que n'importe quel outil graphique. Si vraiment il faut quelque chose c'est un visualisateur du DSL.
PS : il y a beaucoup d'applications « natives » qui sont en fait du cordova ou du phonegap.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par Frank-N-Furter . Évalué à 3.
Ils ont des SWAT Team prêtes a être déployées chez le premier naïf qui commence a développer un binding vers GTK or Qt?
Depending on the time of day, the French go either way.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par DerekSagan . Évalué à 2. Dernière modification le 17 mars 2016 à 15:39.
Non ils ont des SWAT Team qui développent déjà des GUI en Core Graphics sur iOS et OS X 10 fois plus vite depuis XCode sur OS X que n'importe quel développeur ne pourra le faire en Qt s'il doit taper à la main des trucs comme ça qui se font en un ou deux clics avec QtCreator (ou XCode):
Et encore là je te le montre en C++ donc sans se tarter une couche de bindings entre la lib C++ et le langage bindé, Swift ou autre ça change rien.
Et j'ai juste mis un bouton dans une fenêtre, t'imagine quand il y a plusieurs widgets…
Y a qu'à voir le nombre d'appli GUI un peu compliqué qui existe en Qt/C++ et en Qt/Python, le rapport est de genre 100 pour 1, malgré le côté hype de Python et repoussant pour beaucoup de C++.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par groumly . Évalué à 2.
Le mec qui ecrit une gui en coregraphics, il est pas sorti de l'auberge.
C'est une api de dessin bas niveau, un peu comme si tu disais que les dev windows ecrivait leur code en direct2d.
En l'occurence, c'est plutot AppKit et UIKit sous osx et ios en l'occurence.
Apres, oui, les storyboards/xib sont tres bien gaules, mais c'est meme pas que ca qui fait la valeur de cette plateforme, la qualite de l'api en general me ferait la choisir meme sans ce genre de choses (encore que, appkit commence a accuser de son age, mais ya des bons trucs quand meme).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par barmic . Évalué à 3.
QtQuick était pas sensé remplacer QWidget ?
En attendant ce n'est pas le fait qu'il n'existe pas de CoreGraphics qui empêche OCaml, Haskel, go, rust, lisp ou je ne sais quel autre langage d'être utilisé.
Le fait de ne pas avoir accès aux bibliothèques graphiques de Windows n'a pas l'air de te gêner pour faire du C++.
Ça donne vraiment l'impression d'être un caprice « moi je trouve trop joli Core Graphics ! XCode c'est trop bien ! Tant qu'Apple ne me le donne pas comme je veux (sous linux en libre), je boude tout ce qu'ils font ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par groumly . Évalué à -4.
Ben ecoutes, que le monde linux arrete de se branler avec 20 frameworks UI tous pareils mais differents qui petent tout tous les 2-3 ans, qui sont un enfer a deployer, et on sera RAVI de venir coder des clients sous linux.
En l'occurence, swift est ravi de taper dans des libs c, c++ est sur la roadmap (mais encore loin, certes), donc si les devs swift font pas de clients natifs, c'est pas trop la faute au langage.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par Moonz . Évalué à 10. Dernière modification le 11 mars 2016 à 09:12.
Mais de quoi parles-tu ? Tu as deux gros frameworks, Qt et Gtk. Et encore, Qt c’est plus « multiplateforme » que « monde Linux ». Le reste est quantité négligeable — et si tu veux compter les quantités négligeables, les autres OS ont autant voire plus de frameworks UI secondaires à la con utilisés par deux projets (d’autant plus qu’énormément des frameworks secondaires sont multiplateformes). Et tu n’as pas à tout supporter. Tu as juste à en choisir un.
Ça me fait penser à ceux qui ressortent sans cesse cette image pour dire « le son sous Linux c’est le bordel », en passant sous silence que les 3/4 des trucs cités là dedans sont des libs/serveurs de sons portables qui existent ailleurs, et que ailleurs aussi tu as généralement plusieurs API pour accéder au son (sous Windows par exemple tu as à minima DirectAudio et l’API legacy des MFC).
Ha oui
apt-get install libqt4c’est vraiment un enfer de complexité de déploiement.[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Qt semble une évidence à supporter. Mais je pense tout de même qu'une GUI purement fonctionnel (arbre+type sum) serait plus facile à utiliser en ocaml qu'un truc objet.
Ensuite, il doit être possible de faire un "proxy" fonctionnel des truc Qt, mais cela ne doit pas être simple.
"La première sécurité est la liberté"
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par groumly . Évalué à 4.
Et combien de DE different, en combien de versions differentes?
Quand t'en choisi finalement un, que donne l'integrarion dans les autre?
Quels maux de tetes vais je avoir si je fais qq chose de non trivial, a devoir tester sur n versions differentes de m distribs?
Et combien de temps vais je devoir passer a reecrire du code qui marche plus parce que qt/gtk sont montes en version?
Qt3 -> qt4 etait douloureux, 4->5 ca va, mais ya des trucs qui petent.
Gtk 2->3 pete plein de trucs, et n'est meme pas compatible binaire. Ca veut dire que je suis OBLIGE de passer du temps sur mon appli si je veux qu'elle continue a tourner. C'est just du temps gaché, a reecrire du code qui marche tres bien, juste pour qu'elle puisse demarrer, tout ca pour 0 ameliorations, que ca soit pour moi ou mes utilisateurs.
Et effectivement, UI etait de trop dans mon message. Qt/gtk va te donner des fenetres, cool. Maintenant, je doit stocker un mot de passe, je fait comment?
Je veux afficher des notifications, je fait comment?
Je veux interagir avec le desktop, badger une icone du dock/tray, mettre une icone sur le desktop, je sais pas, n'importe quoi dans ce tonneau, je fais comment?
Libqt4, ou 5? Quelle version est packagee? Si je suis sous gnome, comment je m'assure que je tire les packages de compat? Et si je suis sous xfce?
C'est precisement le pobleme, l'integration est un cauchemard. Alors, certes, je suis a peu pres sur que j'aurais une fenetre qui va s'afficher, oui, mais j'ose esperer que la barre est un peu plus haut que ca, et qu'on veut que 100% de l'appli marche dans 100% des cas.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par Florian.J . Évalué à 2.
Je connais pas GTK, mais je connais assez bien Qt, donc je peux pas ne pas y répondre.
Je passe outre l'histoire sur les versions des libs, il y a pas vraiment de solution. Où alors un truc à la Windows, créer une archive qui contient la plupart des dépendances à ton programme.
Si tu développes du logiciel libre (GPL ou LGPL), tu peux distribuer séparément les sources et dans une autre archive avoir un paquet contenant les binaires, la licence de Qt le permet…
Pas très bien compris la question, parce que si il est question d'afficher une fenêtre contenant un message de notification, Qt est quand même adapté à cette situation il me semble ^
En lisant la doc ?
QDesktopServices: https://doc.qt.io/qt-5/qdesktopservices.html
QDesktopWidget: https://doc.qt.io/qt-5/qdesktopwidget.html
QSystemTrayIcon: https://doc.qt.io/qt-5/qsystemtrayicon.html
Pour créer un raccourcis .desktop, à ma connaissance il y a pas, mais bon c'est limite aussi rapide à faire soi même, un coup de Qfile pour écrire dessus est basta. Je pense même pas que ça vaille le coup de l'inclure dans la bibliothèque.
Voir premier point, encore une fois, ça dépend aussi de la manière dont tu distribues ton logiciel.
Cette critique sur le versionnage est valide pour tout l'écosystème Linux, mais tu peux contourner simplement ces problèmes (encore une fois, soit via les sources, soit via une distribution binaire).
Dans le cas de Qt, je te conseille (à tout hasard, peut être est-ce déjà le cas) de ne jamais distribuer de binaire compiler avec une version de Qt spécifique à ta distribution, mais utiliser les archives fournies par Digia qui sont plus génériques.
Dans le cas de ton code, tu peux contrôler la version de Qt utilisé par le compilateur via la macro QT_VERSION ou QT_VERSION_CHECK()
C'est vraiment de la mauvaise foi, je n'ai jamais vu de réel problème entre distributions Linux. Qu'entre Linux et Windows par exemple, tu ais des petites différences d'affichage, je veux bien (et encore en ce qui me concerne, ce ne sont que des différences visuelles, mais jamais de problèmes fonctionnels), mais à version de Qt équivalente le résultat est le même, faut pas déconner.
Alors après effectivement d'une version à l'autre ça change, mais dans ce cas, ce que tu reproche à Qt, c'est d'évoluer et d'avancer ?
Qt, comme tout logiciel évolue, de nouvelles choses apparaissent, certaines choses sont revues et parfois certaines disparaissent, c'est comme ça pour tout le monde. C'est vraiment injuste de dire tant de mal alors que si je m'en fie à tes messages précédents, tu n'as même pas pris la peine de te renseigner et lire la documentation.
Donc insulter un logiciel qui demande tant de travail (et probablement autant pour Gtk, mais je peux pas le défendre sans le connaitre) alors que tu ne sembles pas vouloir faire le moindre effort, c'est vraiment de la [ insérer ici un mot de son choix, que la modération ne laisserait pas passer ].
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par groumly . Évalué à 2.
Ah bon? Et ils font comment osx/ios/windows (je met pas android, trop facile avec des jars).
QSettings quand les os viennent tous avec une keychain, c'est un peu ballot quand meme, surtout dans le contexte actuel.
Effectivement pour les qdesktop et qtraymachin (c'est a ca que je pensais avec les notifications).
Et voila, ca commence. Fait pas ci, fait ca, parce que t'as aucune idee de ce qui va etre dispo sur la machine cible, dans quelle version, sous quel nom de package.
Equivalente est le mot cle. Comme tout le monde integre une version differente, et que different desktop ont un niveau d'integration different, tu te retrouve a gerer des problemes a la con.
Ios et osx evoluent beaucoup mais ne petent JAMAIS la compat binaire. Apple met un effort monstrueux a maintenir la compat d'appli en fonction du framework auquels elles ont ete linkees, et ca monte en version facile.
Quand tu rebuildes, au pire t'as tres tres peu de modif a faire, et qq warnings de deprecation qui apparaissent.
Windows est connu pour garder 100% de compat sur des decennies
On peut visiblement pas en dire autant du passage gtk 2->3 ou de qt 3->4, meme la migration 4->5 pete des trucs si j'en croit leur docs.
Ola! Stop ton char. J'insulte nullement qt/gtk. Je reponds a un commentaire qui disait que l'interet de swift, c'etait les frameworks gui, et insinuait que ca ne servait a rien sur linux.
Mon point c'est que le language n'importe pas tant que ca, que swift sera ravi de lier du c (et dans le futur du c++), et wu'il faut peut etre chercher ailleurs, notamment le fait que developer pour le desktop linux est un enfer qui n'a strictement rien a voir avec le langage.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par whity . Évalué à 5.
En ce qui concerne Qt, la politique est très claire : la compatibilité binaire (ainsi que la compatibilité comportementale) est préservée tant que tu restes sur la même version majeure.
Ensuite, plusieurs versions majeures de Qt peuvent cohabiter sur le même système. Si tu as une licence commerciale, tu peux aussi linker en statique, et donc t’assurer que ton appli va tourner avec la version de Qt que tu as choisie.
Tes critiques sont valables pour énormément de projets libres, mais pour le coup, avec Qt, tu prends vraiment un mauvais exemple : c’est l’un des meilleurs élèves qui soient dans le domaine du support et de la compatibilité source et binaire.
Pour rappel :
* qt3 : sorti en octobre 2001, je ne trouve pas la date de fin du support, mais elle doit être quelque part autour de 2010 (de mémoire, qt3 était encore inclus dans lenny qui date de 2009)
* qt4 : sorti en juin 2005, toujours maintenu
* qt5 : sorti en décembre 2012
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par Lutin . Évalué à 2.
Et wxWidget alors ? C'est un gros aussi, non ?
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par DerekSagan . Évalué à 2. Dernière modification le 17 mars 2016 à 15:57.
Ça change rien. Même qu'il y en aurait vraiment 20. C'est juste un package à installer (ou une dépendance à mettre au package de ton appli si elle est packagée).
Ou une lib à embarquer dans ton bundle d'install si tu veux vraiment pas profiter du gestionnaire de packages des distribs Linux et la jouer comme sous Windows et MacOS X et installer toutes tes dépendances avec toi dans ton répertoire d'appli.
En gros la "complexité" liée au différents toolkits graphiques n'existe que si on veut profiter/rentrer dans le moule du gestionnaire de packages. Parce qu'en fait des toolkits graphiques sous Windows (et dans une moindre mesure sous MacOS X) il y en a au moins autant que sous Linux. Juste les développeurs les packagent avec leur appli et ils sont installés plusieurs fois.
Si tu vas dans C:\Program Files\Gimp tu vas trouver tout gtk et ses dépendances, et à côté dans C:\Program Files\Pidgin t'as de nouveau tout gtk et ses dépendances (pas forcément dans les mêmes versions), etc. même si en théorie on peut partager des bibliothèques en les bourrant dans C:\Windows.
Et sous MacOS X, bah de toute façon c'est la norme Apple de livrer toutes les dépendances dans toutes les applis (ça s'appelle un bundle et si tu fais pas ça t'as pas le droit d'aller dans l'app store mac).
En fait groumly il a juste pas réussi à se rendre compte que ce dont il se plaint est parfaitement facultatif et n'est qu'un service supplémentaire offert par les distribs Linux mais que rien ne l'empêche de la jouer comme chez les sagouinsW leaders du marché. Et ça c'est le cas optimiste, parce que si ça se trouve groumly a compris et il fait juste du troll ou du fud.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par xcomcmdr . Évalué à 3. Dernière modification le 17 mars 2016 à 19:05.
Alors pour appuyer ton propos, sous Windows on a / a eu pour faire une UI :
- Les MFC
- Win32
- WinForms (wrapper en .NET pour les contrôles offerts par Win32, et la librairie graphique 2D software GDI+)
- WPF
- Silverlight (équivalent à Flash)
- Modern UI
- Applications universelles (remplace Modern UI)
Ce qui fait que :
- WPF a été porté de 2006 jusqu'à avant la sortie de Windows 8. La première techno (avec Silverlight) à utiliser le XAML. Aujourd'hui, c'est toujours utilisable, mais pas une techno d'avenir. Sur ce dernier point, WinForms et les MFC rejoignent WPF.
- Silverlight a eu lui aussi une durée de vie plutôt courte
- Modern UI a vécu entre 2012 et 2015… (un peu comme WinRT, qui est repartie comme il est venu :p ). Alors certes les "apps universels" c'est plus ou moins la même chose (XAML, etc…), mais c'est fou comme "Modern UI" a été vite remplacé, du moins de nom.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par DerekSagan . Évalué à 2.
Plus 2 ou 3 trucs un peu cross-platform comme Qt ou gtk.
# Swift open source, vraiment?
Posté par fredoche . Évalué à -1.
J'ai suivi avec une relative attention les annonce au sujet de la libération de swift.
J'essaye de la mettre en perspective avec le fait que, par ailleurs, Apple envisage comme cible, pour ses compilateurs, de "bitcode", un langage intermédiaire ayant vocation à ensuite être recompilé selon l'architecture cible(iOS, apple watch, etc).
Du coup, est ce que Apple s'est engagé à écrire un bon compilateur pour les plates formes historiques (linux, windows, etc), ou est ce que le compilateur livré est un jouet (ou un cheval de troie) pour diffuser le langage, tandis que les vraies avancées de performance seront consacrées à la création d'un meilleur "bitcode" (inutile ailleurs que sur les machines Apple), et les compilateurs bitcode->cpu cible, tranquillement gardées au chaud, cachées dans le cloud Apple, propulsés par LLVM comme sa licence l'autorise?
[^] # Re: Swift open source, vraiment?
Posté par flan (site web personnel) . Évalué à 7.
Le compilateur sera LLVM qui est essentiellement un truc d'Apple (pour se débarrasser de GCC) et qui est réutilisé à toutes les sauces maintenant.
# Bonne introduction, mais...
Posté par procauxfiefs . Évalué à 1.
Je me suis arraché les cheveux pour savoir pourquoi l'importation du module Foundation échouait.
Pour une installation directe sous Ubuntu, il faut, en fait, installer la branche développement et pas celle en parution.
J'aurai du m'en douter à la vue du fichier d'initialisation de vagrant (swift-2.2-SNAPSHOT), mais ça n'a pas tilté.
Merci pour cette mise en jambes.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.