Troy McClure a écrit 2213 commentaires

Avec une très sympathique application de dessin participatif:

http://ocsigen.org/graffiti/

En tout cas le mac mini n'a pas reçu beaucoup d'amour pendant cette keynote puisqu'il a été expedié en 2 minutes à la fin, et on peut noter que le modele "server" qui avait un core-i7 quad-core a disparu, il n'y a plus maintenant que des dual-core…

ARM ou pas ARM pour le mac mini ? ça serait un véritable coup de tonnerre

Oui, c'est typiquement une approximation de 1/sqrt sur 11 bits qui est fournie par les processeurs modernes via les instructions sse / vmx / neon etc (peut etre même en faisant des calculs similaires niveau hardware à ceux de quake ! qui sait). Si l'utilisateur veut une sqrt de precision superieure il doit faire une ou deux iterations de newton pour raffiner le resultat.

On pourrait même discuter de l'aspect mathématique de certaines approximations numériques (séries de Taylor, etc), qui consistent à prendre un résultat mathématique (une série infinie) et à le tronquer pour l'implémenter dans un algorithme.

Y'a quand meme une iteration de newton-raphson dans l'algo en question, ça me semble être un parfait exemple de ce que tu cites

Mouais franchement les trucs mentionnés dans le blog ci-dessus ça va pas chercher loin comme même, c'est pas hyper beau mais de là à le qualifier de shockingly bad c'est abusé. Le style K&R : on s'en fout. Les variables globales: c'est pas beau, mais au moins elles ont des noms bien longs et descriptifs , donc ça va, un coup de grep et on voit qui les utilise. La syntaxe un peu curieuse d'une boucle for: y'a pas de quoi en faire un plat. L'utilisation de strcpy: ça reflete l'age du soft, ça veut pas dire non plus que c'est un gruyère truffé de failles.

Franchement j'aime pas trop ce genre de posts où des donneurs de leçon bien opportunistes viennent se faire mousser en montrant du doigt le code des autres

oh vraiment ? et tu peux prouver que tu es plus efficace avec ton gros debuggeur lourdingue ? J'en doute. Moi je ne sors le debugger que pour les bugs triviaux (genre ca segfault). Le reste du temps, les bugs un peu plus vicieux et compliqués , c'est au printf + affichage de stack trace. Je ne vois pas ce qu'un debuggeur apporte de plus a part de la lourdeur et de la fragilité.

qu'est-ce qui est triste exactement ?

Peut etre aussi qu'au fond les debuggers c'est un peu de la merde, ça passe son temps à perdre les symboles de debug ou à afficher de la merde parce que le niveau d'optim est trop fort, et que ce n'est pas si indispensable que ça.

Tu devrais essayer d'inverser l'ordre des mots dans tes phrases.

Ca te ferait parler comme Yoda.

Ca serait rigolo.

Et si je m'amuse à faire coin coin pendant que je barbote dans la piscine, que va-t-il m'arriver ?

Ils font ça pendant le toucher rectal

Enfin un commentaire pertinent.

Merci.

Tu prends vraiment le compilateur (et le processeur) pour une truffe. Ce genre de micro optimizations où on remplace les indices par des pointeurs n'ont aucun interet en général. Je t'annonce que 99% du temps ça ne fera aucune différence, et le 1% du temps restant ça fera une difference ridiculement faible.

Un dev C aurait utilisé une arithmétique de pointeurs, un dev C++ des itérateurs.

ça aurait changé quoi à l'arrivée ? rien, le code n'irait ni plus vite ni moins vite.

aussi vieux mais plus mieux

J'avais bonne espoir qu'un des deux bots qui sont présents sur la tribune libre serait le premier à passer le test de turing avec succès, malheureusement "deeplop" a encore un peu de mal à faire des phrases qui tiennent debout, et "Single" est un peu trop répétitif et monomaniaque pour faire illusion. Dommage.

Il faudrait surtout que GTK de façon générale recommence à envoyer du rêve, c'est triste mais on est un peu loin de l'époque où une appli en GTK était de fait cool et sexy, où on s'extasiait devant les plus beaux thèmes pour gtk. L'époque aussi où GTK était incontestablement le vrai toolkit natif de Linux. Maintenant les gens n'ont plus que Qt à la bouche, qui pourtant a l'énorme inconvénient d'être écrit en c++, ce qui rend les bindings vers les autres langages nettement plus compliqués.

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 )

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)

Perso j'ai plutot l'avis opposé je suis d'accord pour les exceptions mais pas trop pour le RTTI.

-fno-exceptions pour les virer avec gcc , par defaut elles ne sont pas activées avec visual c++ ( il faut mettre /EHsc )

LLVM se passe des deux, on dirait: http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions

Et puis au passage, écrire des bibliothèque en template ont l'avantage de ne pas surcharger le binaire final si on ne s'en sert pas. "You don't pay for what you don't use"

Si le linker fait bien son boulot d'elimination du code mort dans tous les cas tu ne payes pas pour ce que tu n'utilises pas (on pourrait aussi rajouter qu'avec les templates tu payes déjà le prix fort en temps de compilation)

La difference entre midi et OSC c'est que midi a une norme qui definit clairement comment sont codés les messages note-on note-off etc. Alors que OSC c'est pas beaucoup plus qu'un format de serialisation des donnees: c'est plus ouvert, on peut faire plus de choses, mais ça ne specifie pas autant de détails que le MIDI par rapport aux applications musicales, du coup c'est le bordel.

Tout ça pour dire qu'il faudra ajouter quelque chose à OSC si on veut qu'il remplace un jour le MIDI.

Faudrait aussi qu'un daltonien vienne chouiner comme quoi gnagnagna on distingue pas le rouge du magenta