informatique et high-tech (les meilleures news) %) - Page 215

lol, svp rebondissez plutôt sur les posts pertinents…

Je ne connais pas .Net, mais j'en ai toujours entendu du bien, même si ce n'est pas très étonnant (.Net est pas mal inspiré de Java, et MS a sûrement pu éviter de faire les mêmes erreurs du coup).

Boing boing
à mon avis ce qui empêche caml d'être très largement utilisé c'est de ne pas avoir une grosse stdlib qui permet de tout faire et (et c'est lié) de ne pas être poussé par 2-3 très grosses boîtes, mais autrement c'est bien plus intuitif et on fait beaucoup moins d'erreurs connes qu'en java par exemple ; en plus l'évaluation immédiate est un gros atout, j'ai du mal à utiliser un langage qui n'a pas ça... je ne vois vraiment pas en quoi ça nécessiterait « trop de cerveau »

Je sais pas comment vous pouvez préférer Caml à Scheme ou Lisp, sa syntaxe est abominable

BF FTW! \o/

lol , c'est bien la première fois que j'entends ça
Sinon la différence n'est pas que la syntaxe (heureusement sinon ce serait un peu du foutage de gueule ) : le caml est statiquement typé, en particulier. (Mais bon je dois avouer que la syntaxe joue un peu dans ma préférence, je trouve pas celle du lisp si lisible que ça )

edit (cross) : le ook

Ook? Ook? Syntax error!

./6418 : juste par curiosité, et aussi parceque je suis très naïf, il y a des points précis sur lesquels le framework .NET te semble mal conçu ? (il va sans dire que la considération "libre/propriétaire" est hors-sujet par rapport à cette question)

Bah, les plus grands problèmes:
[ul][li]Certaines APIs (genre W.Forms) ne sont par définition pas portables.[/li][li]Interpréter du bytecode est forcément plus lent que du code natif bien optimisé (critique que j'ai aussi envers le Java).[/li][/ul]

(et si on trollait dans un autre sujet ?)

Kevin Kofler (./6429) :
Bah, les plus grands problèmes:
[ul][li]Certaines APIs (genre W.Forms) ne sont par définition pas portables.[/li][li]Interpréter du bytecode est forcément plus lent que du code natif bien optimisé (critique que j'ai aussi envers le Java).[/li][/ul]

Bizzarement comme le .NET est généralement toujours compilé avant execution...
(et tout toolkit graphique NATIF n'est pas portable, c'est con mais c'est comme ça)

edit: ./6430 Oui tu as raison

Perso, j'aime pas les trucs portables, on obtient des logiciels qui se contentent du plus petit dénominateur commun entre tous les OS, et qui n'en exploitent réellement aucun

Ou qui utilise un toolkit de 500Mo pour singer le toolkit natif et qui n'y arrive généralement meme pas a le faire bien

C'est quand même sacrément pratique en informatique de gestion (et c'est un concept qui date beaucoup : 4D permet ça depuis 1995, par exemple).

À propos de la portabilité ?
Oui, c'est sûr, ça a son intérêt, c'est évident, mais globalement entre un logiciel bien conçu pour une plate-forme donnée et un logiciel qui a été porté directement, y a souvent pas photo.

Sally (./6423) :
Boing boing
à mon avis ce qui empêche caml d'être très largement utilisé c'est de ne pas avoir une grosse stdlib qui permet de tout faire et (et c'est lié) de ne pas être poussé par 2-3 très grosses boîtes, mais autrement c'est bien plus intuitif et on fait beaucoup moins d'erreurs connes qu'en java par exemple ; en plus l'évaluation immédiate est un gros atout, j'ai du mal à utiliser un langage qui n'a pas ça... je ne vois vraiment pas en quoi ça nécessiterait « trop de cerveau »

Merci pour le
Je trouve qu’un programme impératif est souvent bien plus lisible qu’un programme fonctionnel (en tout cas en Caml, je ne connais aucun autre langage fonctionnel) : j’ai besoin de réfléchir pour comprendre ce qui se passe dans le programme fonctionnel (l’absence de typage explicite n’aidant pas, d’ailleurs), alors que dans les programmes impératifs se lisent comme on lit une histoire.

Et, pour avoir discuté de ça un peu avec d’autres personnes, je sais que je ne suis pas le seul dans ce cas. On est souvent d’accord pour dire que Caml est un langage robuste et puissant, mais qui nécessite souvent de se faire des nœuds au cerveau (surtout si on veut rester sur une approche purement fonctionnelle, sans références).

(quant à une stdlib, je trouve qu’il y a plein de bindings vers plein de libs — peut-être moins qu’avec Python, mais quand même)

n'est pas Je pense que c'est sans doute une question d'habitude, personnellement je trouve un programme impératif souvent plus difficile à lire au contraire, surtout quand les algorithmes/structures de données sont compliqués (évidemment si c'est pour écrire hello world c'est différent ^^). Enfin plus précisément pour faire des trucs basiques les deux styles se valent, ensuite suivant les structures de données/algorithmes l'un sera souvent plus adapté que l'autre... mais caml permet de mélanger les deux de toute façon ^^

Sasume (./6436) :
l’absence de typage explicite n’aidant pas, d’ailleurs

Mais le toplevel/le fichier .mli sont là pour ça, effectivement si tu veux lire du code tiers non commenté c'est plus facile si tu n'essayes pas de deviner les signatures par toi-même, mais souvent il y aura un fichier .mli et sinon le compilateur te les donne les types, il suffit de lui demander.

Sasume (./6436) :
surtout si on veut rester sur une approche purement fonctionnelle, sans références

Ben euh oui mais autant je comprends qu'on puisse te conseiller de faire ça quand tu n'as jamais touché un langage fonctionnel et que tu n'as fait que du C ou du basic, juste pour te forcer à apprendre le langage et éviter que tu codes exactement comme en C en mettant des références partout quand c'est pas du tout le plus simple, autant les références sont quand même là pour qu'on s'en serve. Si tu ne veux pas de références autant coder en haskell ou un truc du genre.

Je sais pas, c'est un peu comme quand on dit aux gens qui viennent de l'asm de ne pas abuser de goto en C : le truc c'est qu'il ne faut pas foncer bêtement sur l'utilisation de références par défaut avant d'avoir réfléchi (et le fait est que c'est pas *très* souvent nécessaire d'utiliser des références), *mais* parfois c'est la solution la plus simple et c'est pas non plus la peine de se faire chier à écrire dix lignes de code tordu pour éviter ça. De même qu'ils n'ont pas mis le mot-clef while dans le langage juste pour faire joli ^^

Enfin sinon, tu as programmé combien en caml ? et dans un langage impératif ? parce que évidemment si tu as fait 10 ans de C avant de regarder du code caml pendant 10 minutes ça va te paraître bizarre, mais c'est pas pour ça que ça nécessite « trop de cerveau ». (Je peux te dire que quand j'ai commencé à regarder du C j'ai trouvé ça imbitable, et je suis sûr qu'utiliser correctement les pointeurs et les opérateurs * et &, par exemple — choses que j'ai eu l'honneur de devoir expliquer à des étudiants à plusieurs reprises — ben pour certaines personnes ça demande trop de cerveau, aussi... et pourtant c'est tout ce qu'il y a d'impératif )

Bon et puis ça nécessite peut-être plus de temps par ligne de code de comprendre du caml que du java, mais en même temps comme il y a beaucoup moins de lignes de code pour faire la même chose, je suis pas forcément certain que ce soit plus long/difficile de comprendre un truc entier

Sasume (./6436) :
(quant à une stdlib, je trouve qu’il y a plein de bindings vers plein de libs — peut-être moins qu’avec Python, mais quand même)

Je comparais surtout à java, en fait ^^ (mais bon ça fait longtemps que j'ai pas essayé de coder un gros truc en caml — ou plus généralement que j'ai pas essayé de coder une application, tout court, en quoi que ce soit, d'ailleurs ^^, ça a peut-être évolué en bien). Ça reste plus compliqué de chercher sur le net, d'installer les bindings etc. que de juste dl le jdk avec tout dedans. Enfin si ça n'est plus le cas, tant mieux

Sally (./6437) :

Sasume (./6436) :
l’absence de typage explicite n’aidant pas, d’ailleurs

Mais le toplevel/le fichier .mli sont là pour ça, effectivement si tu veux lire du code tiers non commenté c'est plus facile si tu n'essayes pas de deviner les signatures par toi-même, mais souvent il y aura un fichier .mli et sinon le compilateur te les donne les types, il suffit de lui demander.

Je suis bien d’accord mais toutes ces informations sont plus accessibles quand on lit un programme Java par exemple.

Enfin sinon, tu as programmé combien en caml ?

8 semaines.

et dans un langage impératif ?

8 ans.

Ouais y peut-être de ça aussi

Flanker (./6405) :
Les extensions, de mémoire ?

Passage de 25 à 50mos tu veux dire?

Bin j'ai fouillé vite fait les préférences, j'ai vu aucune allusion aux extensions.
Trop rien de plus à première vue, mais avec un numericable qui dépote, ça fait des chargements d'affichage yaronet en moins d'1/2s. Youtube moins d'une seconde. (je parle pas du téléchargement des pages mais bien du rendering)

Voilà j'ai mes réponses:

Concernant la BETA de la Galerie d’Extensions, notez qu’elle regroupe déja plus de 300 extensions mais que celles-ci ne sont pour le moment disponibles/compatibles que pour les utilisateurs Windows et Linux, les Mac Users devront une nouvelle fois patienter…

(source: http://www.nowhereelse.fr/google-chrome-beta-mac-linux-extensions-27015/)

http://www.lemonde.fr/technologies/article/2009/12/07/un-proces-a-60-milliards-de-dollars-pour-l-industrie-du-disque-canadienne_1277338_651865.html

#squalyl#

Oui, j’ai repêché ça du vidage du presse-papier, mais comme ce n’était pas encore dans LE topic idoine (à savoir celui-là), non, ce n’est pas un #squalyl# …

C'est quoi cette URL ils auraient dû rajouter encore deux ou trois zéros tant qu'à faire...
( topics/76711-les-meilleures-news/498 : il s'agit bien d'un #squalyl#, c'était déjà dans les meilleures niouz, ça correspond à la définition — même si flan n'a peut-être pas choisi le bon topic de niouz et si c'est donc un #squalyl# excusable dans une certaine mesure)

Ethaniel (./6443) :
à savoir celui-là

Je suppose que tu veux dire celui-ci

C'est pas spécialement informatique ni high-tech

http://www.numerama.com/magazine/14648-si-l-acta-est-rendu-public-maintenant-des-participants-quitteront-la-table-maj.html

( http://www.newscientist.com/article/mg20427375.200-net-piracy-the-people-vs-the-entertainment-industry.html )

flan > Oui j'allais dire que la limite entre les deux topics n'a jamais été clairement définie (d'après moi c'était censé être les articles de geek qui n'intéressent que trois personnes ici¹ et les articles susceptibles d'intéresser un peu plus de monde dans les meilleures niouz tout court, ce qui était censé permettre de ne pas lire celui-ci, mais malheureusement ça n'a pas été correctement interprété par tout le monde et maintenant il y a des articles intéressants ici )

...mais donc le fait est que presque toutes les niouz sur le piratage et par extension les majors du disque se sont trouvées ici, et dans cette mesure on pourrait considérer que par tradition ton article y avait sa place, même si je tendrais dans l'absolu à être d'accord avec toi ^^

¹Typiquement les niouz pour ici étaient la sortie de la nouvelle version de windows/macOS/fedora/je ne sais quoi etc., qui polluaient l'autre topic.

Sally (./6444) :

Ethaniel (./6443) :
à savoir celui-là

Je suppose que tu veux dire celui-ci

Mh, exact, toutes mes confuses …

Sally (./6447) :
...mais donc le fait est que presque toutes les niouz sur le piratage et par extension les majors du disque se sont trouvées ici, et dans cette mesure on pourrait considérer que par tradition ton article y avait sa place

C’est effectivement un placement de facto, établi je dirais à l’époque des débats Hadopi qui ont eu une grande résonance dans ce topic-ci.


Bon allez, une « vraie » news « hi-tech », avec du Nintendo à l’intérieur : http://www.lemonde.fr/technologies/article/2009/12/07/piratage-de-jeux-video-bataille-juridique-sur-la-vente-de-linkers_1277273_651865.html

Godzil (./6431) :
(et tout toolkit graphique NATIF n'est pas portable, c'est con mais c'est comme ça)

On peut faire une API portable autour des toolkits natifs, cf. wxWidgets, SWT etc. Ou alors on fait comme Qt et on fait un toolkit portable qui utilise les fonctions d'affichage natives là où le toolkit portable n'est pas le toolkit natif, l'avantage est que c'est plus facile d'obtenir quelque chose de complètement portable (pas besoin de couvrir les limitations bizarres des toolkits natifs), le désavantage, c'est que c'est plus difficile d'obtenir un comportement identique à celui du toolkit natif (du point de vue de l'utilisateur). Donc les 2 approches ont leurs avantages et leurs inconvénients.

Mais utiliser directement le toolkit natif n'est absolument pas possible dans la librarie standard d'un langage qui se veut "multiplateforme" (mais malheureusement, pour eux, "multiplateforme" ne se limite qu'au matériel avec toujours le même OS, ou au mieux les "plateformes" sont la série NT et la série CE, OS certes différents, mais du même producteur et avec des APIs qui ressemblent beaucoup).

Ils ont perdu un procès pour avoir essayé d'introduire des APIs monoplateforme dans leur version de Java, du coup ils ont copié Java avec C# et .NET, ce qui leur a permis de faire exactement ça. Ironiquement, tout le reste du monde peut introduire ce genre d'APIs dans Java maintenant avec OpenJDK. Mais je ne vois pas Apple ni les distributeurs GNU/Linux se lancer sur ce genre de choses, demandez-vous pourquoi.

y a un autre sujet pour troller…