[F] [mOved] Mon langage est mieux que le tien - Page 116

Ça fait cher en cafés du coup.

Meowcate (./3451) :
Ça fait cher en cafés du coup.

En java, quoi.

C'était la blague... sur le double sens de "prendre un café" en guise de rendez-vous, et le café comme "java", comme la signification étrangère, le logo du soft, et... euh... hm...

Meow: elles ont des noms a rallonge, pas évident pour s'en souvenir après le verre au bar (on peut leur offrir des haricots, elles savent s'en servir). Puis elles travaillent souvent en usine, à des postes en solo. Par contre en cas d'inattendu, elles savent toujours quoi faire!

Mwai... après réflexion, je ne roule pas sur l'or, et il parait justement qu'elles nécessitent pas mal de ressources. Ça doit être lié avec le fait qu'elles sont réputées pour prendre pas mal de poids avec l'âge.

Du coup, les bébés javanais, ce sont des Java Micro Edition ?

LOL

Par contre avec Tom le chat elles rendent plein de services sur le web.

Ce n'est pas une raison pour prendre tout ce qu'elles te disent pour parole d'Oracle.

D'ailleurs, c'est un Tomcat transgenre, vu qu'en interne "il" s'appelle Catalina.

Une nouvelle de SF sympa si vous avez un peu de temps à tuer : https://www.teamten.com/lawrence/writings/coding-machines/

(et oui, il y a un rapport avec le code, raison pour laquelle je poste le lien dans ce topic )

J'adore ^^

Bon j'ai commencé à lire ./3461 mais ça fait quand même bizarre de lire une nouvelle qui ressemble autant au boulot je trouve (et puis je n'arrive pas à m'empêcher de penser qu'il essaie de prouver quelque chose en essayant de caser autant d'exemples concrets que possible, au moins pendant la première moitié, du coup je n'ai pas réussi à m’immerger vraiment ; ça vaut le coup d'insister ?)

Je l'ai lu, et je dirais un "meh". Déjà, cela s'adresse à un public résolument technique. Même en essayant d'expliquer certains concepts, ce n'est pas à donner à lire à n'importe qui.
Le final de l'histoire, les machines prennent conscience à cherchant à développer leur propre code et utilisent de petites équipes humaines pour tester leurs failles afin de corriger ces erreurs pour la génération suivante, je n'ai pas été très convaincu. Toute l'histoire tourne autour de "on ne comprend pas ce qui se passe, on essaie des tas de méthodes pour debugger ce qui nous échappe totalement". On peut tous voir d'où cette histoire a été inspiré, dans le quotidien de tout un codeur face à des moments d'incompréhension envers le fonctionnement, au final relativement opaque, de sa machine (on voit ce qui entre, ce qui sort, mais on n'examine que très rarement les rouages).

Dans ce genre, j'y préfère de loin l'approche de Etaoin Shrdlu. Même s'il y a des éléments spécifiques à la technologie de la machine, l'histoire s'apprécie tout autant et les motivations des différents protagonistes sont plus viables.

Ouais au début ça ressemble à une chasse au bug "classique", mais le vrai développement de l'histoire se fait vers la fin. Perso j'ai bien aimé, si tu as le courage d'aller jusqu'au bout je suis curieux d'avoir ton avis, vu que je sais que tu apprécies ce genre

Sinon ç'a été écrit par un codeur (cf. le reste de son site), donc je ne pense pas que les références techniques soient là pour prouver quoi que ce soit, c'est simplement destiné à un public de codeurs (raison pour laquelle j'ai posté le lien dans le topic). Mais ça reste une histoire de SF quand même, parce que tout n'est pas réaliste.

Putain mes bugs des fois

"Bon, on va multiplier ce nombre par 256 dans cette itération (low endian -> big)" :
multiplier >> 8;
Débogage. "Ah oui, mince, quel con"

On recommence :
multiplier << 8;
Débogage. "Ah oui, minde, quel super con"

On remet ça :
multiplier <<= 8;
Ah purée enfin

T'as pas eu ton café ce matin ?

En plus c'est vrai, j'en ai pas pris

Je sens que les trolls qui proposent d'écrire multiplier *= 256; ou multiplier *= 0x100; ne vont pas tarder à venir.

Personnellement, j'écrirais aussi multiplier <<= 8; en tout cas.

Que fait le compilateur?

Moralité si on veux vraiment dire "on decale de 8" c'est ok.
Si on veux faire des maths, ce n'est pas ok car rends le code peu lisible, et n'apporte aucune optimisation, parce que le compilateur n'est pas idiot.

Et le volatile est la pour forcer le compilateur a ne pas produire ce code:

main: mov eax, 24576 ret

Bah de toute façon le résultat technique est le même : les compilateurs savent optimiser les multiplications par des puissances de deux.
Donc je dirais que tout dépend de la logique de l'opération. Si il s'agit d'une opération qui a un sens du point de vue binaire, les décalages se justifient. Mais s'il s'agit de faire une multiplication autant utiliser l'opérateur fait pour.

Uther (./3472) :
Donc je dirais que tout dépend de la logique de l'opération. Si il s'agit d'une opération qui a un sens du point de vue binaire, les décalages se justifient. Mais s'il s'agit de faire une multiplication autant utiliser l'opérateur fait pour.

Ça rend le code plus lisible.

(Dans le même genre : https://stackoverflow.com/questions/5213338/fastest-way-to-flip-the-sign-of-a-double-float-in-c )

Comme quoi je peux prévoir le futur… (Cf. ./3470.)

Kevin Kofler (./3475) :


Comme quoi je peux prévoir le futur… (Cf. ./3470.)

bah nan, t'as parlé de troll alors que les réponses sont étayées et argumentées...

vince (./3476):

Kevin Kofler (./3475) :


Comme quoi je peux prévoir le futur… (Cf. ./3470.)

bah nan, t'as parlé de troll alors que les réponses sont étayées et argumentées...

Si tu n'es pas d'accord avec KK c'est que tu es un troll

Arvi89 (./3477) :

vince (./3476):

Kevin Kofler (./3475) :


Comme quoi je peux prévoir le futur… (Cf. ./3470.)

bah nan, t'as parlé de troll alors que les réponses sont étayées et argumentées...

Si tu n'es pas d'accord avec KK c'est que tu es un troll

C'est la déduction qui en découle naturellement...

./3467 : pour les deux premiers trucs, le compilo ne t'a pas mis un warning "code has no effect" (ou message similaire) ?

Et sinon, si c'est du code de conversion d'endianess, écrire "<<= 8" est plus logique que "*= 256", vu que l'opération qu'on cherche à effectuer est justement un décalage de bits. Ce n'est pas comme si on multipliait par une constante qui est égale à 256 par pure coïncidence (auquel cas, il serait plus logique d'écrire "*= 256").

(au passage le sens du shift pour diviser ou multiplier n'a aucun liens avec l'endianess)