Axioplase ıɥs∀ a écrit 3042 commentaires

Une montre. Ça existait avant les smartphones.

L'écrit, c'est très bien. Demande à tes correspondants de communiquer uniquement en "です/ます" et d'éviter autant que possible le langage familier. Ainsi, tu communiqueras dans un langage neutre utilisable à l'oral aussi. Je pense que les sites sus-nommés devraient t'aider à trouver des gens qui pourront corriger ton japonais.

Pour l'anglais, BBC learning English ou Voice of America, et de l'imitation des dialogues des podcasts…

Ha, je remarque que tu parles du japonais… Quel est ton niveau ? Quel est ton objectif ?
Si c'est juste communiquer que tu veux, alors ces sites sont bien. Si c'est parler, un site avec webcam et/ou micro peut être mieux, ou simplement des rencontres avec des japonais dans ta ville.
Si c'est obtenir un niveaux professionel à l'écrit, je te conseille directement d'aller pêcher dans les resources en japonais pour japonais, car l'écrit (et l'oral aussi, d'ailleurs) au travail, c'est une tout autre langue…
Sinon, un bon bouquin, un bon dico, et du temps passé à traduire, ça marche aussi. Choisis quand même un livre moderne et simple à lire, genre Murakami Haruki, si tu veux apprendre du japonais que les gens comprendrons. Si tu apprends avec Natsume Sôseki ou Umehara Takeshi, tes interlocuteurs ne vont pas comprendre la moitié de ton vocabulaire…

J'utilisais palabea autrefois. Pas mal de gens autour de moi utilisaient lang-8 aussi.
Mais bon, maintenant, j'ai assez d'amis autour de moi qui parlent les langues que j'apprends ou perfectionne…

B et P sont difficiles à distinguer.
づ et ず sont difficiles à distinguer.
Dans le dialecte que je parle, K et G, T et D, す et し sont très très similaires.

Smalltalk/Squeak!

Y'a des macros en HTML?
Y'a des outils aussi avancés que PGF/tikz pour faire des graphes et schémas ?

Je passe sur la gestion de l'espacement et des césures qui ont déjà été cités…

Certains langages te proposent de sauvegarder ta session REPL dans un binaire. Tu peux donc faire bien plus que des choses simples: tu codes, tu charges dans la REPL, tu corriges en patchant dynamiquement, et tu sauvegardes ta REPL. Pouf, t'as un binaire qui fait ce que tu veux.

J'ai pas lu Clancy, mais SAS, c'est des gros pistolets et des gros seins. C'est pas mal en son genre, assez rigolo à lire, mais je préfère largement un bon San Antonio. Même un mauvais.

Je n'accuse pas, je dis ce que je comprends en lisant le texte, c'est tout. Ton illustrateur dit que c'est exactement ainsi que sont traités les artistes, et c'est justement pour ça que je prends la plume et dit que c'est pas un modèle bénéfique pour la main d'œuvre.

Si votre projet marche en recrutant des bénévoles, tant mieux pour vous ! Je vais pas vous empêcher de le faire, ni vos codeurs de vous rejoindre ! Mais votre message me parait plus être un désir d'exploitation qu'un appel à contributions.

Pour résumer, voilà l'impression que j'ai eue (et que j'ai toujours) : http://monmacon.tumblr.com/post/51459258309/grand-concours-pour-realiser-laffiche-flyer-logo

Enfin, quand je vois les réponses de ton genre, je me demande si on doit compter sur la bonté de l'espèce humaine dans notre entreprise.

C'est bien la question. Si tu demandais de l'aide pour un logiciel qui aide les aveugles, handicapés, ou je-ne-sais-qui, alors oui, tu pourrais compter sur la bonté d'autrui. Un truc révolutionaire, pourquoi pas. Mais là, le projet ne semble pas avoir ce genre d'objectif. Ça ressemble plutôt à "on veut que des gens fassent le boulot pour qu'on s'amuse à notre jeu. En plus, si on le vend, on aura des sous. Et comme t'auras travaillé bénévolement et bien sûr sans contrat, ben on te payera comme on le voudra, quand on le voudra. Mais ça, tu t'en fous vu que tu travailles juste pour le plaisir, hein ?!" Et ça, c'est pas jouer sur la bonté d'autrui, c'est jouer sur sa naïveté, et ce n'est pas vraiment le genre de valeurs auxquelles j'adhère.

Ma vision est sans doute arrêtée et résignée, mais elle est surtout concrète : tout travail mérite salaire.

Compte tenu de nos finances, nous cherchons des bénévoles.

Tu veux dire, de votre absence de finances, non ?

Je comprends qu'on puisse espérer recruter de la main d'œuvre qui travaille bénévolement, et ça marche plutôt bien dans le domaine du LL. Cela dit, ça marche surtout pour des applications déjà existantes, crois-je, et de manière spontanée. Mais là, ça n'a pas l'air d'être le cas. Des gens avec des idées et pas un rond, y'en a plein. Et c'est pas grave : le reste du monde se passe très bien de ces idées qui ne voient jamais le jour et dont il n'a jamais entendu parler.

Bref, les « j'ai une idée, codez le gratuitement pour moi, » j'aime pas. Code ton jeu toi-même, attend des offres de gens qui désirent d'eux-mêmes t'aider, mais ne promeut pas le travail gratuit.

Cela étant, je trouve les visuels de ton projet très bons.

Je peux t'aider. Donne moi ton numéro de carte, sa date d'expiration, et son cryptogramme (les numéros à l'arrière de la carte). Je vais tenter de faire un achat avec, et je vais te dire si ça marche ou si t'as effectivement un problème avec ta carte :)

Je crois qu'on y arrive très bien (avec des élevages d'araignées). Le problème, c'est qu'on n'arrive pas à en produire en quantité industrielle.

Tes quatre familles, elles sont cinq…

Manux ? Souvenir de moule ?

T'es sûr que tu parles pas de Manix ?

Je -->[]
(Ok, bon, cet art ascii est encore plus suggestif, maintenant !)

Pourquoi des guillemets autour de "BlackBerry" ?

Est-ce que ce journal vous a plu ?

Oui

Est-ce que ça vaut le coup de s'en inspirer pour écrire une Dépêche ? (la partie historique)

Oui, si tu développes un peu plus et rajoute des liens vers (ou directement imbrique) des images, voire si tu montres un chouilla de code expliquant comment ils diffèrent à l'usage.

Quels sont vos expériences sur les interfaces ? graphique ou console ?

ncurses codé à la mano… Pas beaucoup, d'ailleurs.

Quel langage auriez vous utilisé pour pour détecter des fichiers dupliqués et aider l'utilisateur à choisir lesquels à effacer ?

Perl, bien sûr ! Aucun besoin d'apprendre un autre langage…
À la limite, mon shell, si le script n'a à offrir aucune fonctionalité supplémentaire et/ou non-triviale.

si on peut calculer length, on peut résoudre le problème de l’arrêt)

Euh, vraiment ? Ça suffit ? Un langage avec uniquement la déconstruction de listes et la création d'entiers naturels par incrémentation, c'est suffisant pour être Turing-complet ? Ça me parait bien insuffisant…

Je réitère: map n'échoue pas en Haskell, ou alors ton programme entier plante, et c'est pas la faute de map, mais de la fonction que tu mappes. Dire que map échoue, c'est un peu comme dire qu'un "IF" échoue. Si c'est le cas, c'est pas la faute du IF lui-même, mais de ce que tu fais dedans (et d'ailleurs, avec map, on garantit trivialement que c'est pas le test du if qui échoue mais le contenu du then ou du else, donc la fonction qu'on applique et pas map lui-même).

Je n'ai aucune idée de ce que map veut dire dans mongodb, mais le map fonctionel, celui d'Haskell, Lisp, ML et consorts, il n'échoue pas, et ça n'a donc aucun sens de vouloir faire un failover.

Quant à ton avis sur les méthodes formelles, sans rentrer dans les débats philosophoques (car il y en a), il me parait bien mal informé. Personellement, je suis bien content que la branlette universitaire prouve l'absence de bugs dans l'informatique embarquée des avions que je prend et dans le matériel médical utilisé pour les radios et scanners que je subis.

Map n'échoue pas. Eventuellement, la fonction que tu mappes échoue. Mais alors, t'as un bug dans ton code, et retenter map n'y changera rien.

Il y a un risque à cause des règles d'évaluation paresseuses du langage.
Il faut parfois aider un peu en forçant l'évaluation (eg, via l'extention BangPatterns de GHC) l'évaluation. Sinon, tu crées des thunks en mémoire et risque au final le débordement de pile/tas, pas forcément à cause de l'adresse de retour, mais à cause des paramètres de l'appel récursif.
Exemple:

fac 100000 met quatre fois plus de tems que fac2 100000 sur mon PC:

{-#LANGUAGE BangPatterns #-}

fac n = fac' n 1
  where
  fac' 1 acc = acc
  fac' n acc = fac' (n-1) (n * acc)

fac2 n = fac' n 1
  where
  fac' 1 !acc = acc
  fac' n !acc = fac' (n-1) (n * acc)

Cela dit, c'est ptet plus un débordement de tas que de pile…

Parce que ça ne vaut pas le coût/coup : créer un thread/spark/autre peut coûter plus cher qu'évaluer séquentiellement a et b.
Pour avoir fait de la programmation parallèle en Haskell dans mon précédent job, j'ai bien compris que c'était pas évident de faire un programme parallèle et efficace (et souvent, tu dois aussi jouer avec les directives de forcage d'évaluation (les "bang patterns") afin d'éviter de créer trop de fermetures en mémoire).

Pour prendre un exemple que tu auras du mal à caractériser comme tiré par les cheveux, ça veut dire quoi exactement la phase ci dessous ?
SHE IS AN ENGLISH TEACHER

C'est contextuel:  elle est professeure d'anglais, elle est professeure anglaise. Rien de nouveau sous le soleil ; des ambiguïtés, ça se trouve dans toutes les langues naturelles (et ça peut toujours s'éviter avec une reformulation « she is a teacher of English, she is a teacher from England » ). J'imagine que la résolution d'ambiguïté est ton point, mais l'absence d'ambiguïté n'est à mon avis pas suffisant pour affirmer que la langue plus simple à apprendre ou utiliser.
On pourrait créer une grammaire avec plus de temps qu'en français, plus de déclinaisons, cas et genres qu'en polonais, et aucune ambiguïté.

Je ne dis pas que l'esperanto est une mauvaise idée, je dis juste que les bases de la grammaire anglais sont suffisement simples.

grâce à la flexibilité et puissance de la grammaire, tu peux souvent dire les choses de plusieurs manières, en mettant les mots dans l'ordre qui exprime le mieux ta pensée ou qui semble le plus naturel (ce qui est important pour les peuples ou l'ordre sujet-verbe-complément n'est pas l'ordre standard)

C'est aussi exactement ce qui va créer encore plus de difficultés pour les gens dont la langue est radicalement différente du modèle SVO : le choix les embrouille, car leur approche de l'apprentissage de la langue repose souvent sur des systématismes, et le naturel n'a pas lieu d'être. Réordonner les mots pour indiquer une nuance risque alors de fortement les embarasser car ils doivent alors apprendre un nombre exponentiel de cas grammaticaux et les traduire dans leur langue pour comprendre les bases de la grammaire. Par ailleurs, la notion de « naturel » n'existe pas dans l'esprit de quelqu'un qui ne maîtrise pas déjà la langue…