Journal Apple annonce Swift, son nouveau langage de programmation

Posté par  . Licence CC By‑SA.
Étiquettes :
28
2
juin
2014

Une nouvelle guerre est lancée et chacun veut en être. Pourquoi ? Aucune idée, mais tout le monde y va de son langage de programmation.

Partant du constat que C c'est beurk, trop bas niveau, gérer la mémoire manuellement c'est has been, que C++ c'est beurk, trop complexe, gérer la mémoire manuellement c'est has been et que les langages actuels ont le défaut d'être… actuels, il était grand temps de se lancer dans la création d'un nouveau langage.

Petit tour d'horizon des derniers langages les plus en vogue du moment:

  • Google lance Go, pour créer des logiciels simples, fiables et efficaces.
  • Mozilla réplique avec Rust, un langage étonnement rapide qui permet d'éviter presque tous plantages et autres erreurs de concurrences.
  • Facebook avec Hack, promet de réconcilier le développement rapide que permet PHP par l'apport du typage statique.

Histoire de ne pas être en reste (on ne sait jamais sur quelle case la roue s'arrêtera de tourner), Apple avance ses pions avec Swift, à ne pas confondre avec Swift, un langage de script parallèle pour environnement réparti ou la Suzuki Swift, une voiture.

On notera que la WWDC (Apple World Wide Developer Conference) n'étant pas encore terminée, la documentation sur ce nouveau langage est plutôt rare..

Bon ben alors what's new? Swift, c'est de l'Objective-C sans le C. Avec, on peu définir des variables… et faire à peu prêt tout ce que l'on retrouve dans les langages actuels. Pour moi pas de grandes révolution. On retrouve les concepts à la mode du moment tels les Closures, les retours de valeur multiple et à première vue, je ne distingue pas de grandes différences avec Rust.

Apple se devait de rentrer dans la courses des langages nextgen et gageons que plus il y a de langages et plus il y a de chances qu'un développeur trouve celui qui lui convient le mieux.

  • # Le futur te rattrape toujours

    Posté par  . Évalué à 10.

    Rien ne vaut le LISP.

    • [^] # Re: Le futur te rattrape toujours

      Posté par  . Évalué à 10.

      J'avoue avoir pensé à la même chose en lisant ce passage :

      On retrouve les concepts à la mode du moment tels les Closures, les retours de valeur multiple

      J'ai l'impression qu'on n'invente plus grand chose depuis 30 ans mais qu'on se contente de remettre progressivement à la mode des concepts qu'on a perdu depuis la grande époque du C/C++/Java

      • [^] # Re: Le futur te rattrape toujours

        Posté par  (site web personnel) . Évalué à 6.

        Un nouveau langage qui ne gère pas le tail recursive (comme Rust), ni les types sommes et le filtrage, c'est assez inutile, IMHO.

        "La première sécurité est la liberté"

        • [^] # Re: Le futur te rattrape toujours

          Posté par  . Évalué à 5.

          Il n’optimise pas les appels récursifs terminaux ? Étonnant. D'après cette discussion, il optimise les « sibling calls » (appel terminal à une fonction de signature équivalente), ce qui devrait suffire dans ce cas puisqu’une fonction a forcément la même signature qu’elle-même.

        • [^] # Re: Le futur te rattrape toujours

          Posté par  (site web personnel) . Évalué à 4.

          C'est pas ce genre de choses là, le filtrage ? :

          switch somePoint {
case (0, 0):
println("(0, 0) is at the origin")
case (_, 0):
println("(\(somePoint.0), 0) is on the x-axis")
case (0, _):
println("(0, \(somePoint.1)) is on the y-axis")
case (-2...2, -2...2):
println("(\(somePoint.0), \(somePoint.1)) is inside the box")
default:
println("(\(somePoint.0), \(somePoint.1)) is outside of the box")
}

          ( https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html#//apple_ref/doc/uid/TP40014097-CH9-XID_161 )

          • [^] # Re: Le futur te rattrape toujours

            Posté par  (site web personnel) . Évalué à 5.

            si.

            en ocaml, cela permet de faire des truc comme :

            type expr =
      | Plus of expr * expr        (* means a + b *)
      | Minus of expr * expr       (* means a - b *)
      | Times of expr * expr       (* means a * b *)
      | Divide of expr * expr      (* means a / b *)
      | Value of string            (* "x", "y", "n", etc. *);;

let factorize e =
    match e with
    | Plus (Times (e1, e2), Times (e3, e4)) when e1 = e3 ->
       Times (e1, Plus (e2, e4))
    | Plus (Times (e1, e2), Times (e3, e4)) when e2 = e4 ->
       Times (Plus (e1, e3), e4)
    | e -> e;;

# factorize (Plus (Times (Value "n", Value "x"),
                   Times (Value "n", Value "y")));;
- : expr = Times (Value "n", Plus (Value "x", Value "y"))

            "La première sécurité est la liberté"

            • [^] # Re: Le futur te rattrape toujours

              Posté par  . Évalué à 5.

              Je n'ai rien compris (je n'ai jamais fait d'OCaml).

              • [^] # Re: Le futur te rattrape toujours

                Posté par  (site web personnel) . Évalué à 4.

                Tu peux voir "Plus" "Minus" comme des Enum en C, mais les filtres exigent que tous les cas soient traités.

                Ensuite, "match" regarde à l'intérieur d'un type "expr", il décompose l'expression, et affecte les feuilles à "e1" "e2" "e3", ensuite, ces valeurs sont utilisés pour recomposer la structure de donné (ici, une expression de math).

                "La première sécurité est la liberté"

              • [^] # Re: Le futur te rattrape toujours

                Posté par  . Évalué à 5.

                Un exemple plus simple, et en haskell

                -- on défini un type récursivement, une expression est soit :
data Expression = Somme Expression Expression -- une somme d'expression
                  | Moins Expression -- l'inverse d'une expression
                  | Valeur Int       -- un scalaire

-- là on a le filtrage de motif, la fonction eval est défini différemment suivant le constructeur qu'on lui donne en paramètre
eval (Valeur v) = v
eval (Moins e) = -(eval e)
eval (Somme e1 e2) = eval e1 + eval e2

                Dans un langage genre C on ferait

                switch(e.constructeur) {
case Valeur:
    return e.v;
case Somme:
    return eval(e.op1) + eval(e.op2);
.
.
.

                Please do not feed the trolls

    • [^] # Re: Le futur te rattrape toujours

      Posté par  (site web personnel) . Évalué à 0.

      Rien ne vaut le LISP.

      Un langage qui brûle les lèvres (Lisp stick).

      kentoc'h mervel eget bezan saotred

  • # Documentation

    Posté par  . Évalué à 5.

    La doc est là https://developer.apple.com/swift/
    A noter que la microarchitecture des microprocesseur A6 et A6X Arm par apple s'appelle aussi Swift …

  • # Le nom...

    Posté par  . Évalué à 10.

    SWIFT, c'est aussi le système qui sert (servait ?) à faire des virements bancaires.

    Ça sort pas mal en ce moment, les nouveaux langages, en effet, mais par contre, pour ce qui est de faire preuve d'imagination ou au moins d'un peu d'esprit pratique dans le choix des noms, c'est vraiment pas ça. Ça va être pratique pour faire des recherches sur le Web…

    • [^] # Re: Le nom...

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 03 juin 2014 à 01:28.

      On devra faire des recherches du style « swiftcar », « swiftarch », « swiftlang », etc. :)

      (on use déjà les mots clés « clang » et « golang »…)

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Le nom...

        Posté par  . Évalué à 7.

        Hem…
        Pas si sûr que ta requête fonctionne:
        http://swift-lang.org/

      • [^] # Re: Le nom...

        Posté par  . Évalué à 10.

        Hum, clang, c'est un compilateur, ça m'étonnerait que ça retourne les résultats espérés.

        Quant à Go : comme avec Swift, ces couillons ont choisi un nom, qui en plus d'être courant (et encore plus dans le cas de Go que dans celui de Swift), était déjà le nom d'un autre langage ! Faut quand même en tenir une couche pour faire de tels choix.

    • [^] # Re: Le nom...

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      C'est aussi le nom d'un client XMPP qui n'est pas trop vilain d'ailleurs. Font pas trop dans l'originalité…

    • [^] # Re: Le nom...

      Posté par  (site web personnel) . Évalué à 4.

      C'est aussi le nom d'un protocole qui se veut être le remplaçant de Bittorrent.

    • [^] # Re: Le nom...

      Posté par  . Évalué à -1.

      Swift, c'est la compensation des échanges en cash, et c'est encore d'actualité si je ne m'abuse.
      Pour les virements interbanques ou à l'international, c'est plus Clearstream/Euroclear etc…

      • [^] # Re: Le nom...

        Posté par  . Évalué à 3.

        Ça parle quand même de virement électronique sur Society_for_Worldwide_Interbank_Financial_Telecommunication

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Le nom...

          Posté par  . Évalué à 3.

          Oui tu peux trouver la liste des messages SWIFT sur leur site. Elle est plutôt large ;)

          Par exemple tu as le MT103 pour les ordres de payement entre deux entités et MT202 entre institution financière. Dans Swift en fait tu as deux choses, le réseau et le protocole de communication et un ensemble de message standardisé pour permettre aux institutions de communiquer de manière plus, ou moins, automatique.

          Bon c'est un peu résumé par ce qu'en pratique c'est un peu plus monstrueusement compliqué que ça :)

          • [^] # Re: Le nom...

            Posté par  . Évalué à 1.

            Je confirme que Swift marche encore, et qu'un virement c'est MT103…

            Il y a des quantités de myards qui passent la-dedans, tous les jours

      • [^] # Re: Le nom...

        Posté par  . Évalué à 3. Dernière modification le 03 juin 2014 à 19:12.

        Pour les virements interbanques ou à l'international, c'est plus Clearstream/Euroclear etc…

        Rien à voir, clearstream et euroclear sont des banques de clearing, elles font du réglement/livraison des titres (actions, obligations…).

        Swift s'occupe bien des virements internationaux, par exemple c'est le registrar des IBAN.

    • [^] # Re: Le nom...

      Posté par  (site web personnel) . Évalué à 2.

      Et c'est le nom du module de stockage objet d'OpenStack…

    • [^] # Re: Le nom...

      Posté par  . Évalué à 4.

      Tu veux dire que Apple serait nul pour choisir ses noms?

      Comment Apple à emprunté le nom HealthKit à une société qui maintenant doit assumer les conséquences…

  • # Moderne ?

    Posté par  . Évalué à 6.

    Ça s'appelle OCaml… C'est très cool, mais pas moderne.

    Please do not feed the trolls

    • [^] # Re: Moderne ?

      Posté par  . Évalué à 5.

      C'est moderne dans un contexte d'intégration par le mainstream des idées de la programmation fonctionnelle. On a un langage avec des fonctions d'ordre supérieur, des types statiques, des options et du filtrage de motif. Ce n'est déjà pas mal !

      Du reste, il y a un travail de vulgarisation qui est fait (par exemple sur le pattern-matching avec un mot-clé let explicite qui souligne que les variables sont en position de lieurs) qui est intéressant.

      (Le but réel est sans doute de re-segmenter le marché pour éviter que des langages qui tournent sur iOS et Android continuent à être les plus populaires. Mais techniquement c'est un bon essai, et un signe de plus que la programmation fonctionnelle a gagné la partie.)

      • [^] # Segmentation et dé-segmentation dans le développement mobile

        Posté par  . Évalué à 3.

        Le but réel est sans doute de re-segmenter le marché pour éviter que des langages qui tournent sur iOS et Android continuent à être les plus populaires.

        Je crois que tu as tout dit !

        Quelqu'un a t'il d'ailleurs des retours d'expérience sur le développement cross-platformes mobile ?
        J'ai vu passer pas mal de choses, en javascript, en ruby, … et aussi la moulinette de Google qui cross compile ton code java en objective C pour les couches bas niveaux, … mais je ne sais à quel degré en sont ces différents projets

        • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

          Posté par  (site web personnel) . Évalué à 7.

          Je crois que tu as tout dit !

          Sauf que swift vient en remplacement de d'objc qui est tout aussi segmentant. Personne en dehors de l'ecosysteme Apple n'utilise ce langage.

          Je pense qu'apple a senti que l'âge d'objc commence à peser pas mal, le langage est quand même plutot barroque et lourdingue et là ils saisissent l'occasion de le remplacer en douceur par un truc plus sexy, et peut être plus performant même si c'est dur de se fier à leurs chiffres pour l'instant (et qu'ils n'ont donné des rapports de vitesse qu'avec python et objc, pas avec des trucs qui vont vraiment vite, et sans preciser la nature des benchmarks)

          • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

            Posté par  . Évalué à 3. Dernière modification le 03 juin 2014 à 11:43.

            Sauf que swift vient en remplacement de d'objc qui est tout aussi segmentant. Personne en dehors de l'ecosysteme Apple n'utilise ce langage.

            Oui c'est bien le sens de la remarque de gasche, telle que je l'ai compris en tout cas :

            Le but réel de 'swift' est de perpétuer cette segmentation du développement mobile qui avantage Apple en érigeant des barrière à l'entrée pour ne pas qu'un nouvel OS mobile rejoue le tour pendable que lui a joué Android.

            • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

              Posté par  (site web personnel) . Évalué à 2.

              Oui enfin, non, s'ils rendaient les autres langages incompatibles… mais c'est pas le cas.

              La majorité de l'OS est écrit en Obj-C/C++/C, Swift va surement être la base de quelques nouveaux Frameworks et des nouvelles apps, les autres langages ne sont ni remplacés ni mis à la poubelle !

              La grande question est : est-ce qu'ils vont pousser upstream le support de Swift dans LLVM !

              • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

                Posté par  (site web personnel) . Évalué à 1.

                Ça ne m'étonnerait pas, Apple l'a fait à plusieurs reprises avec ses technos.

              • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

                Posté par  . Évalué à 3.

                La grande question est : est-ce qu'ils vont pousser upstream le support de Swift dans LLVM !

                Greg parker a dit sur twitter "c'est pas le cas a l'heure actuelle, et j'en ait pas entendu parler".
                Je doute qu'apple libere quoi que ce soit avant la gm d'xcode, attendue en septembre.
                Cela dit, ils ont libere le compilo arm 64 bits, donc pas trop de raison de pas liberer cette partie de clang quand ils seront pret - ca leur avait prit qq mois pour nettoyer le tout et faire la release publique.

                A noter que chris lattner a dit lundi "le language est toujours en beta, si on garanti la compatibilite binaire, ca sera pas forcement le cas avec la compat source des prochaines release, mais on va essayer d'etre cool et d'au moin vous filer un outil de migration, 'fin si on peut".
                Ce qui peut expliquer pourquoi ils sont pas presse de releaser le tout publiquement.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

            Posté par  . Évalué à 3.

            et peut être plus performant même si c'est dur de se fier à leurs chiffres pour l'instant

            Apple n'est pas connu pour gruger les benchmarks (c'est meme plutot le contraire), surtout vu comment leurs annonces font du bruit.

            (et qu'ils n'ont donné des rapports de vitesse qu'avec python et objc, pas avec des trucs qui vont vraiment vite, et sans preciser la nature des benchmarks)

            Mouiii, enfin objc enterre tout ce qui se fait sur plateforme mobile, et de tres tres loin, et n'a pas a rougir face a du c++. Fait qq tests sur arm 64 bits si tu me croit, une tres grosse partie de l'overhead est partie en fumee dans les tagged pointers, et le reste, ben c'est du c, donc bon.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

              Posté par  . Évalué à 4.

              Mouiii, enfin objc enterre tout ce qui se fait sur plateforme mobile, et de tres tres loin, et n'a pas a rougir face a du c++.

              Et si on fait du C++ sur plateforme mobile ?

              Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

              • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

                Posté par  . Évalué à 3.

                On peut pas vraiment dire que ca soit courant, la majorité, c'est du java ou de l'objc, et après ca les technos web donc JS et consorts.

                J'aime beaucoup java, j'en écrit plein cote serveur, mais cote client, c'est loin d'être ca, meme avec le travail monstrueux de google sur leur concurrent GC. Quand tu lit les experts dire "le seul moyen de pas se taper des pauses GC, c'est de faire très attention a pas allouer d'objet", ca fait pas rêver.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

          Posté par  (site web personnel) . Évalué à 10.

          Quelqu'un a t'il d'ailleurs des retours d'expérience sur le développement cross-platformes mobile ?
          J'ai vu passer pas mal de choses, en javascript, en ruby, … et aussi la moulinette de Google qui cross compile ton code java en objective C pour les couches bas niveaux

          Une autre solution est de tout faire en c++, avec Qt. Ça permet d'avoir un seul code source et de le faire tourner sous win, mac, linux, iOS, Android (blackberry aussi je crois mais pas testé) et avec QML une interface qui peut être sympa sur tous les devices.
          Et côté perf c'est plutôt pas mal.
          En tout cas pour le moment je trouve que c'est une des meilleurs solutions pour faire une application sur plusieurs plateformes.

          • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

            Posté par  (site web personnel) . Évalué à 3.

            Je trouve également que Qt est la meilleure solution pour faire du multi-plate-forme. En revanche, il faut être conscient que le résultat ne sera pas spécialement bien intégré (voire sera assez laid) au reste du système, en tout cas sur certaines plates-formes comme OS X.

            • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

              Posté par  (site web personnel) . Évalué à 3.

              laid ? pourtant même si c'est pas parfait Qt permet justement d'avoir un rendu natif assez bien fait sous osx. Par exemple si on regarde QtCreator n'est pas horrible sous mac.
              Après évidemment faire du multiplateforme (desktop + android + ios) et avoir une interface parfaite partout (ie respectant les guidelines partout) c'est un poil compliqué…

              • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

                Posté par  (site web personnel) . Évalué à 4.

                Ça dépend pas mal des widgets que tu utilises. Pour certains ça passe (ou c'est nickel), pour d'autres ça ne passe pas du tout.
                Accessoirement, être correctement intégré à OS X ne s'arrête pas à adopter le style graphique : ça veut également dire utiliser les TextBox (pour avoir par exemple le même correcteur orthographique et grammatical que le reste des applications, ou la synthèse et la reconnaissance vocale), le trousseau d'accès (mots de passe, certificats, clefs privées), les raccourcis claviers gérés par le système, etc. Pour ce genre de choses, Qt est assez mauvais (mais il faut reconnaître que ce n'est pas facile à faire en étant multi-plate-forme !).

                • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

                  Posté par  (site web personnel) . Évalué à 3.

                  Ok, je vois ce que tu veux dire.
                  Et qu'est ce qui serait mieux comme solution multi plateforme ? (vrai question)

                  • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

                    Posté par  . Évalué à 1. Dernière modification le 04 juin 2014 à 07:59.

                    (on parle bien de dev desktop maintenant ? sinon désolé du hors sujet)

                    "Mieux", je ne sais pas, c'est subjectif et ça dépend beaucoup du type d'application.

                    Mais Chrome en tant que plateforme de développement multi-plateforme (windows, mac, linux, chrome os, … y'a même un projet pour android et ios) est dans bien plus de cas qu'on ne pourrait l'imaginer a priori une solution efficace !

                    Chrome Apps --> http://developer.chrome.com/apps/about_apps.html
                    Suivre François Beaufort --> https://plus.google.com/+FrancoisBeaufort/about

                  • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

                    Posté par  (site web personnel) . Évalué à 1.

                    Je n'ai pas dit qu'il y en avait une :D

                    si tu veux faire une application vraiment bien, il eau utiliser le toolkit de la plate-forme. Et dans tous les cas, il faudra un minimum de code spécifique à chaque plate-forme.

                  • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

                    Posté par  . Évalué à 3.

                    Rien. Le code multiplateforme en terme d'UI sera toujours ni fait ni a faire, par design (denominateur commun a toutes les plateformes, soit un ecran avec des pixels, un clavier et une souris. Pas grand chose quoi).

                    Tu veux releaser sur os "bidule", prend le taureau par les cornes et ecrit du code pour os "bidule". Garde ton domaine ecrit dans un langage "generique", portable, ya pas de mal, mais si c'est pour faire un travail de porc avec une UI "one size fits all", t'as limite mieux fait de faire une web app, au moins les gens sauront a quoi s'attendre.

                    Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                    • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

                      Posté par  (site web personnel) . Évalué à 3.

                      Garde ton domaine ecrit dans un langage "generique", portable, ya pas de mal

                      Rien que ça c'est déjà un très bon avantage. Après je sais pas trop comment on peut mixer vraiment avec les applis natives android et ios, mais si on peut déjà avoir tout le métier écrit une seule fois et juste l'interface à changer, c'est déjà très bien.

                      Ensuite, tout comme il existe des qt mac extras et qt windows extras (par exemple pour gérer la barre de tache sous windows 7/8) ajouter des choses du genre permettrait d'avoir un seul code et une intégration assez poussée. J'espère que ça ira dans ce sens.

                      Mais après tout dépend le but de l'appli. Si c'est pour faire un flappy truc, pas besoin d'une intégration UI poussée ;-)

                    • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

                      Posté par  . Évalué à 0.

                      Je ne suis pas d'accord avec toi.

                      On ne peut pas par définition faire mieux intégré à un OS qu'en utilisant les API natives. Mais comme l'intégration n'est qu'un critère parmi d'autres qui fait que le logiciel a une réelle proposition de valeur pour l'utiliseur, si le fait d'utiliser une autre plate-forme de développement te permet de toucher plus vite plus de gens et d'itérer plus vite, ça contre-blance—et parfois largement—le désavantage de départ.

                      Deux exemples parmi mes marottes :
                      - en 2004, gmail (basé sur des apis web pourries à l'époque) était mieux qu'outlook express (natif)
                      - aujourd'hui, pour les gens qui écrivent non plus pour leur imprimante mais pour les écrans, il y a toute une série d'outils (google docs, etherpad, byword, workflowy, gingko, …) qui sont meilleurs que le mastodonte natif Microsoft Office.

                    • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

                      Posté par  (site web personnel) . Évalué à 5.

                      A priori en Qt 5.4 (la prochaine version) QML devrait reprendre le style des composants d'UI natifs d'Android. Donc plutôt un bon point pour ça.

          • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

            Posté par  . Évalué à 4.

            Il y a Xamarin qui semble t'il le fait bien, mais je n'ai jamais essaye. Je serais d'ailleurs assez interesse par les retours de gens qui l'ont essaye.

            • [^] # Re: Segmentation et dé-segmentation dans le développement mobile

              Posté par  (site web personnel) . Évalué à 3.

              C'est vrai, pas essayé pour le moment. Mais le peu que j'ai tenté avec Xamarin Studio sous Mac ne m'a pas vraiment donné envie. l'IDE est juste horrible et j'ai pas été convaincu par rapport à Qt niveau productivité, et côté interface QML c'est vraiment sympa.
              Mais ça vaudrait le coup de tenter quand même.

  • # Messages

    Posté par  . Évalué à 1.

    Swift, c'est de l'Objective-C sans le C.

    Ça utilise le passage de messages comme en Objective-C ?

    • [^] # Re: Messages

      Posté par  (site web personnel) . Évalué à 2.

      Probablement quand tu utilises les bindings vers ObjC.
      Après, au runtime et si tu restes en Swift, je pense que c'est autre chose (un bon vieux pointeur de fonction?).

    • [^] # Re: Messages

      Posté par  (site web personnel) . Évalué à 2.

      Je suppose que le runtime de swift est le même qu'Objective-C et qu'il génère un code compatible, l'Objective-C à un runtime simple et efficace qui permet une architecture super souple et évolutive mais avec du code compilé, c'est la base d'iOS et OS X, je doute qu'ils aient abandonné ça !

    • [^] # Re: Messages

      Posté par  . Évalué à 2.

      Vtable a l'anchienne si t'es en swift pur (d'ou le mot cle override obligatoire), ca passe par objc_msg_send si tu sousclasse une classe objc.

      C'est tres en ligne avec ce qu'a fait apple dernierement, une philosophie "on optimize a bloc dans le meilleur des cas, et on degrade les performances pour retrouver un status quo dans le pire cas".

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # « …plus il y a de chances qu'un développeur trouve celui qui lui convient le mieux »

    Posté par  (site web personnel) . Évalué à 2.

    Tant qu'il y a de la vie, il y a de l'espoir.

    Il me semble d'ailleurs avoir trouver une faute nuisant à l'intelligibilité de votre journal :

    s/y vas/y va
    s/rester en rester/rester en reste
    s/on ne c'est jamais/on ne sait jamais (ou on ne C jamais ?)

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # Une application par serveur, un langage par système d'exploitation

    Posté par  . Évalué à 7.

    Au début, le langage est développé pour répondre à un besoin perso en se disant : "on va l'étendre qu'il serve un peu partout". Puis il commence à être utilisé majoritairement au sein de l'application sans jamais être étendu.

    Au final, il faut connaître le langage de l'application avant de coder dans l'application.

  • # Mais, Mais ....

    Posté par  . Évalué à 10.

    et la licence alors ?
    http://programmers.stackexchange.com/questions/242853/what-are-the-licensing-terms-for-the-swift-programming-language

    Allez Rebol nous l'a déjà faite… aux oubliettes direct

  • # Typo

    Posté par  (site web personnel) . Évalué à 1.

    Désolé mais je suis presque devenu aveugle.

    on ne c'est jamais sur quelle case la roue s'arrêtera de tourner

    Je pense que le verbe savoir était l'idée première de l'auteur et non le verbe être.

    Du coup on ne sait jamais

    kentoc'h mervel eget bezan saotred

    • [^] # Re: Typo

      Posté par  (site web personnel) . Évalué à 3.

      tellement aveugle que tu n'as pas vu les commentaires ;-)

      • [^] # Re: Typo

        Posté par  . Évalué à 1.

        En même temps pour voir mon commentaire qui relève cette faute il faut voir les commentaires négatifs… Peut-être que certains pensent que c'est moi qui me trompe?

        • [^] # Re: Typo

          Posté par  . Évalué à 5.

          Oui, sait toi qui te trompe !

          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Typo

        Posté par  (site web personnel) . Évalué à 1.

        tellement aveugle que tu n'as pas vu les commentaires ;-)

        Oui mais moi j'ai fais un sujet Typo qui veut dire ce qu'il veut dire avec la faute en gras et pas un titre de 2 Km avec les fautes corrigées en regex au beau milieu de 42 autres commentaires.

        NA ! :-D

        kentoc'h mervel eget bezan saotred

        • [^] # Re: Typo

          Posté par  (site web personnel) . Évalué à 3.

          avec les fautes corrigées en regex

          sait triste ton avis sur les regex

          • [^] # Re: Typo

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 04 juin 2014 à 21:37.

            Mais non les regex sait le bien.
            Sait juste que tout le monde ne c'est pas les utiliser.

            kentoc'h mervel eget bezan saotred

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.