@dscreve :
Je veux en savoir plus!

Moi aussi j'aimerais bien en savoir plus

Je ne suis pas du tout d'accord avec tes propos notamment concernant la qualité des applications.

Pour pratiquer les 2 langages Objective-C et Swift, c'est ma profession, avec en plus une solide expérience dans le développement de logiciels critiques je peux t'affirmer que Swift est une bouffée d'air frais par rapport à Objective-C qui va rendre les programmes beaucoup plus robustes et évolutifs.

D'ailleurs ce commentaire me rappelle le passage de l'assembleur à des langages plus évolués, jadis : code pourri et baisse de performances !

@hawker :
Absolument pas d'accord. Ce genre de commentaire me fait penser à cette tranche de développeurs (et je ne peux que souhaiter que tu n'en fasses pas partie) pour qui la qualité passe par la complexité. Ce qui est un non sens!
On voit ces remarques à chaque amélioration qui touche au fait qu'on simplifie une tâche qu'un développeur a mis un peu de temps à maîtriser. Mais rendre les choses simples, c'est aussi rendre ces elements plus accessibles, plus robustes, et permettre au dev de prendre du temps sur un sujet plus abouti.
Ou penses-tu réellement que c'était plus efficace sans ARC, plus lisible sans programmation orientée objet, plus simple à coup d'optimisations en assembleur...?

Justement, Swift permet aux très bon programmeurs de faire de meilleures choses encore.
En quoi penses-tu que le niveau soit plus haut qu'Objectice-C, sinon ?

@hawker

Ce pauvre discours rétrograde… j'espère pour toi que tu codes en kobol et que tu t'éclaires qu'à la bougie, vieux cylon.

@hawker:
Merci de vos précisions. On comprend mieux votre point de vue.
J'avoue, ma réaction initiale à votre premier post a été semblable à celle des autres intervenants, mais on vous a assez tiré dessus à boulets rouges, et, comme Brassens, je n'aime pas les foules qui crient "haro sur le baudet !"

Votre exemple des solvers explique peut-être un malentendu : il y a ceux qui cherchent à réaliser une solution que j'appelle structurelle, viable sur le long terme (pour autant que l'OS s'y prête). Et ceux qui s'efforcent "to get the job done", en un temps donné, produisant un code lisible et adaptable. Ces derniers seront, comme moi, les adeptes de langages de haut niveau, par économie de temps et de priorités, même si le code n'est pas optimisé au max et que l'on gaspille des ressources côté mémoire et CPU.

Je suis assez vieux pour avoir appris la programmation sur un mainframe IBM 3033. Le chef du centre de calcul était un vieux de la vieille, genre "Assembler über alles". S'il avait pu tout faire en langage machine, il l'aurait fait. Après une révolte des utilisateurs, nous sommes passés de JCL au time-sharing, à PL/I, Fortran 77 avec optimizing compiler, et top du top, à APL sur terminal graphique pérennisé dans la linkpack area, avec 512kB de tranche de mémoire par utilisateur. (Sous JCL, nous n'en avions que 32 kB, et les routines en Assembler /360 ne devaient pas dépasser 8kB.)

D'un côté, consommation de ressources croissant de façon exponentielle. Mais de l'autre côté, nous étions enfin productifs: on pouvait résoudre des problèmes au lieu de batailler contre la machine. Et je vous garantis que même il y a 30-35 ans, on aurait donné notre main droite pour programmer un système d'équations linéaires simultanées en APL au lieu d'Assembler ou C (ou même Fortran, à la limite).