> Y'a suffisamment de cas où le compilateur ne fait pas bien son boulot pour lui laisser l'occasion de briller quand c'est plutôt chiant à faire à la main, tu ne trouves pas ?
Qu’on soit clair : je n’ai jamais dit que ce genre de fonctionnalité n’était pas intéressante dans l’absolu. Simplement, je me pose la question du prix à payer pour de telles fonctionnalités. Si c’est pour se taper ensuite des pans entiers de code qui font de la « métaprogrammation » à la C++, merci mais non merci (vous avez déjà essayé de débugger un truc comme ça ? Un an après ? Écrit par quelqu’un d’autre ? Alors, oui, c’est type-safe et puissant, mais…). Si c’est pour avoir un langage qui nécessite une thèse en mathématiques pour comprendre pourquoi le compilateur râle sur ce bout de code alors qu’intuitivement il devrait pas, idem. Et je suis également assez sensible à la complexité du compilateur lui-même, du reste.
Je crois qu’on va là refaire le débat séculaire du « worse is better » : http://www.jwz.org/doc/worse-is-better.html :). Et étant clairement du côté worse-is-better, c’est la raison pour laquelle je me méfie de Scala et privilégie Go. Ce n’est pas un hasard si go a tant de succès auprès de suckless & co.
Enfin, je dis ça, mais apprendre Haskell est sur ma TODO-list depuis un moment ;) (plus pour ma culture que pour une réelle utilisation toutefois)
> Bref, je me demande s'ils ne viennent pas de se tirer une balle dans le pied.
Peut-être bien, mais tant que les autres sont cul-de-jattes (au point de vue de la pertinence des résultats, de la flexibilité d’utilisation, de la légèreté), il lui reste un pied d’avance ;)
Pas moi par exemple, je m’en fiche un peu. À part pour les collections, j’utilise jamais les génériques.
Et j’ai bien peur que ça finisse comme la métaprogrammation en C++ tout ça…
Encore une fois : en quoi le système de type de Go n’est pas fort ? Ce programme ne compile pas parce que Go ne fait pas de conversion implicite entre float et int :
func printFloat(f float) {
print(f)
}
func main() {
var x int = 5
printFloat(x)
}
Il vous faut quoi de plus pour que ce soit du typage fort ?
> et c'est super pas utile en terme d’interopérabilité pour quand on fait des libs et qu'on veut avoir des types qui sont compris de la même façon par tout le monde.
Je crois que tu n’as pas compris leur système d’interfaces. Une même interface est comprise pareille pour tout le monde. Si tu fais un minimum de Go, tu verras par exemple que l’interface Reader est utilisée absolument partout (dans io, http, json, logger,…), et tout le monde la comprend pareil. Idem pour l’interface Error.
> La notion d'interface permet de donner une sémantique à ses méthode
Ben oui, c’est ce que fait une interface en Go ; un ReadWriter, c’est un objet sur lequel on peut lire et écrire.
Ou alors j’ai pas compris ce que tu voulais dire par « donner une sémantique à ses méthodes ».
> et là, justement ce n'est que du structural typing statiquement typé !
En quoi est-ce supposé être en contradiction ?
> avec son typage VRAIMENT avancé (higher-kind et autres trucs du genre)
Par exemple ?
> avec une vraie réflexion sur le lien entre objets et fonctions
Par exemple ?
> (voir tout le travail sur les contraintes sémantiques encodées avec les types pour avoir plus de vérification et de sûreté à la compilation par exemple).
Un lien ?
> ce langage n'a pas de gestion strict du typage.
Qu’est-ce que tu entends par là ?
C’est du typage statique, fort, à inférence locale. Je vois pas ce qu’il te faut de plus. C’est l’inférence locale qui te gène ? Pourquoi ?
> je considère que ce système sacrifie mes libertés. Nous somme dans l'arbitraire
« liberté », « arbitraire », ce sont des concepts constitutionnels et de philosophie politique, absolument rien à voir avec la choucroute (neutralité d’un acteur privé sur internet).
Si Google viole tes libertés, la manière la plus simple d’y remédier est de porter l’affaire devant la justice.
> est clairement une atteinte a libre concurrence et a la libre expression.
Ben porte plainte contre Google alors. Ça aura au moins le mérite de faire rire quelques juristes.
(indice : liberté d’expression ≠ obligation légale de neutralité)
> Est-ce que ce n'est pas plutôt la culture du "mon langage n'a pas la feature X, du coup je clame qu'il est tellement bien qu'on n'en a pas besoin"?
Ben non, vu le nombre de programmeurs compétents, s’il y avait un besoin (d’IDE), t’inquiète que les IDE se mettraient à pousser comme des champignons et que un ou deux sortiraient vite du lot.
D’ailleurs, tu remarqueras que pour Python par exemple, des IDE de très bonne facture existent [http://eric-ide.python-projects.org/], mais sont peu utilisés.
> Je comprends que ca caresse ton ego de tout faire a la main, mais le but du jeu c'est de produire des applis, pas de se mesurer la quequette a base de ki k'est le plus hardcore.
Allez, encore un petit effort et tu pourras être encore plus insultant.
Bon, comme tu as l’air d’être un peu dur à la compréhension, je répète. Tu me dis :
- Java a de bons IDE => Java est un bon langage (plus exactement, tu as dit : la qualité de ses IDE est une mesure de la qualité d’un langage)
Je te dis: c’est faux, parce que la bonne relation de causalité est:
- Java nécessite un IDE pour être utilisé => Java a de bons IDE
Avec, pour argument : de très bons langages, qui ne nécessitent pas d’IDE, ne donnent pas une telle « culture de l’IDE » : Ruby et Python par exemple. L’immense majorité des devs de RoR sont soit sous vim, soit sous TextMate. Ce se sont incompétents ? Des narcissiques qui préfèrent « se mesurer la quequette » plutôt que d’être productifs ?
C++, qui, au niveau « nécessité de l’utilisation d’un IDE », se situe entre Python et Java, ben se situe également entre les deux sur « qualité des IDE » (refactoring moins bon voire inexistant par exemple) et sur « nombre de programmeurs préférant travailler avec un IDE en C++ »
> mais le but du jeu c'est de produire des applis
Putain, j’aurais jamais deviné tout seul. Merci beaucoup de m’avoir prévenu, heureusement que tu es là.
Maintenant, est-ce qu’il ne te serait pas venu à l’esprit que :
- l’utilisation des IDEs a des avantages mais aussi des inconvénients (naoon, pas possible !)
- le poids de ces avantages et de ces inconvénients diffère selon le langage et même la personne (fou hein !)
- et que donc, au niveau productivité, l’utilisation ou non d’un IDE dépend du langage, du projet, et de la personne (bon, je commence à avoir mal à l’épaule à force d’enfoncer des portes ouvertes)
Bon, on reprend ton raisonnement point par point, il y a quelque chose de fallacieux là-dedans.
> si elle est imposé de la même façon qu'un cadre moyen
(H1) en absolu
(H2) en proportionnel
> et que tu trouve cela normal
yep
> et que tu trouve normal que l'impot soit proportionnel à la capacité contributive
yep, avec capacité contributive = revenu
> ca veut donc dire que tu considère que la capacité contributive de Mme bettencourt est identique (en % de sa fortune et/ou revenue) que celle d'un cadre moyen.
Dans le cadre de (H2): ce n’est qu’une reformulation de (H2). Si tu veux dire que (H2) => (H2), pas la peine, je savais depuis un moment (et tes hypothèses intermédiaires ne servent à rien).
Dans le cadre de (H1): ça veut dire que dans mon monde idéal, oui, cette situation implique logiquement que Bettancourt a le même revenu qu’un cadre moyen. Comme ce n’est pas le cas, mon monde idéal n’est pas le monde réel. So what ? Je me répète : je n’avais pas besoin de toi pour m’en rendre compte.
(par ailleurs, 17 milliards, c’est sa fortune, pas son revenu, et en France la base de l’impôt c’est le revenu — sauf pour cet extraterrestre légal qu’est l’ISF)
> Quand aux perfs, tenez vous le pour dit: le jour ou les sites vont rajouter de la pub en overlay sur les video, vous allez voir votre cpu remonter aussi haut qu'il le faisait avec flash.
Ben non, quand tu mets des sous-titres avec mplayer sur une vidéo, il ne désactive pas l’accélération matérielle pour autant. C’est donc que tu peux combiner overlay et accélération matérielle.
> Oui, mais les gens aiment les gros IDE.
Ça, ça dépend complètement du langage. Effectivement, l’immense majorité des devs Java aiment les gros IDE, mais c’est exactement parce que le langage est inutilisable sans (forcément, étant donné que les 3/4 du code sont tellement trivial qu’un IDE peut le générer et qu’un être humain se fait chier à en crever à l’écrire…)
Les développeurs Python, Ruby et PHP n’aiment en général pas les IDE parce que ces derniers sont incapables d’utiliser toute la puissance de leur langage (et pourtant, la puissance de PHP…)
Pour les développeurs C et C++, ça dépend franchement des milieux.
C’est quoi la différence entre « imprévisible » (Java) et « ça dépend » (C++) ? La même qu’entre un bon et un mauvais chasseur ?
> Sauf que la complétion, les opérations de refactoring, de génération de code et de modélisation ne sont souvent bien implémentées que pour Java. C'est bien dommage d'ailleurs!
Refactoring, peut-être (jamais essayé les outils de refactoring d’eclipse dont on me rebat tant les oreilles), pour le reste, tu as totalement craqué, n’importe quel IDE un tant soit peu complet est capable de faire ça pour le C ou le C++
> les conflits de voisinage etc. n'ont rien à faire devant la justice.
C’est vrai, autant qu’ils se règlent à la carabine, ce sera plus calme pour tous les autres voisins ensuite.
> qu'on ne peut résoudre autrement
Raisonnement circulaire. Si deux voisins ont un conflit mais arrivent à s’entendre sur la manière de le résoudre sans faire intervenir la justice, ben par définition ils n’iront pas devant la justice. S’ils n’y sont pas capable, c’est qu’on est pas capable de le résoudre autrement, à moins de rétablir les duels…
> Sinon c'est claquer l'argent du contribuable par les fenêtres.
L’Arbitrage (droit), c’est rendre justice aussi.
> temps de compilation interminable.
Relativement au C, l’écart n’est pas tellement évident sur une machine récente.
(par rapport à du vrai C++ avec des templates de partout, par contre, je suis à 100% d’accord)
> accès concurrents...
Toujours indéfinis en Java, et dans tous les langages que je connais d’ailleurs.
> IDE et outils peu puissants
La plupart des IDE « puissants » sont multi-langage. Quant à des outils puissants, liés au langage, qui auraient contribué au succès de Java, je vois pas.
Le fait que le C soit un langage très très très casse-gueule pour les "noobs", c’est pas une nouveauté hein…
Il est clair que quelqu’un qui a deux ans de « programmation » (comprendre : un DUT informatique) derrière lui, je le met pas dans un projet en C direct, sauf à mettre quelqu’un qui relit chacune de ses lignes derrière.
[troll]
D’ailleurs, c’est pas ça le principe d’un noob fraîchement diplômé, de se charger du code des projets Java-bateau, pour que les personnes plus expérimentées puissent se concentrer sur de vrais projets ?
[/troll]
> Bah ca serait un ajout, pas une modification : le compilateur accepterait, en plus de la signature tab[int] la signature tab[long].
Si C++ interdit la surcharge sur la seule base de la taille d’un type numérique, c’est pas pour rien : c’est très casse-gueule.
Mais bon, je pense (sans ironie) que je ferai mieux de me taire, je connais pas assez le fonctionnement interne des JVM ni même à quoi ressemble le bytecode Java (en dehors que c’est du bytecode).
> Ben en Java c'est pas un hasard.
Dans le sens de coïncidence, pas d’aléatoire.
> La norme Java ne défini pas de type dont le nom comporte le nomber de bits associés.
J’avais oublié ce détail (une des nombreuses raisons que je fuis Java, pourtant… mais si je devais toutes les retenir… mais on s’éloigne du sujet).
Effectivement, je vois pas de meilleure solution que d’encapsuler ça dans une classe et de mettre un commentaire.
> Le passé l'a montré : Java a déjà évolué de nombreuses fois
L’API J2** a évoluée, le langage Java a vu des fonctionnalités ajoutées. Par contre, je n’ai pas vu des fonctionnalités du langage modifiées (ce que serait « bon en fait on s’est planté, les long comme indice d’un tableau, c’est valide… J’aimerais bien voir d’ailleurs comment ils feront pour faire cohabiter les programmes dont le bytecode contient des index de tableaux en int et des index de tableaux en long, mais en même temps je connais pas le bytecode Java). Si tu as des exemples…
> C'est absolument pas une hérésie en Java
Si, de la même manière que new int[(int)math.PI] est une hérésie. Pour la n-ième fois, c’est pas parce qu’une constante marche « par hasard » qu’il est correct de l’utiliser. Si le type de ta variable nécessite sémantiquement une taille définie, tu l’explicites, sinon celui qui reprendra le projet dans 5 ans risque de se casser la tête (il voulait juste un nombre ou il voulait un conteneur pour 32 bits ? Je peux utiliser short pour réduire l’emprunte mémoire étant donné que maintenant on stocke des centaines de millions d’éléments ?)
> tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?
Heu, tous les algos de base pour la manipulation des structures de données : tables de hashage, graphes & arbres, liste chainées, tableaux, qui en pratique scalent selon la taille du type de base (pointeur pour les liste chainées, entier pour le tableau,…)
> Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
En quoi c’est ridicule ?
Comme tu dis toi-même, dans ce cas, le fait que ça marche ou pas ne dépend pas de l’architecture de la machine mais des capacités de la machine.
Ce qui n’est pas en soit surprenant.
> Ca a tout son sens quand ton soft gere 32768
Tu mélanges deux situations différentes. Ton soft gère 32768 éléments ou MAX_INT éléments ? Ce n’est pas la même chose.
Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.
> et on verra regulierement des tables de 2^32 elements
Ha, mais c’est exactement mon argument plus bas, hein !
1. Là où Java est portable dans le sens où il garantit que l’algo aura les mêmes limites partout, là où C est portable dans le sens où l’algo « scale » avec les capacités de la machine.
2. Justement, je suis impatient de voir comment fera Java quand on verra régulièrement des tables de 2^32 éléments, alors qu’il est écrit dans sa spec que l’index d’un tableau, c’est 32 bits.
> Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.
Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.
C’est pas « plus » ou « moins » portable, c’est différent. Pour une FFT fenêtrée de taille fixe sur un stream, l’approche Java est plus adaptée. Pour de la manipulation d’images, l’approche C est plus adaptée (tu aimerais que la limite en taille d’image puisse s’adapter avec l’évolution du matos : images 170 par 170 au max sur du 16 bits, 65000 par 65000).
[^] # Re: typage mou
Posté par Moonz . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 0.
Qu’on soit clair : je n’ai jamais dit que ce genre de fonctionnalité n’était pas intéressante dans l’absolu. Simplement, je me pose la question du prix à payer pour de telles fonctionnalités. Si c’est pour se taper ensuite des pans entiers de code qui font de la « métaprogrammation » à la C++, merci mais non merci (vous avez déjà essayé de débugger un truc comme ça ? Un an après ? Écrit par quelqu’un d’autre ? Alors, oui, c’est type-safe et puissant, mais…). Si c’est pour avoir un langage qui nécessite une thèse en mathématiques pour comprendre pourquoi le compilateur râle sur ce bout de code alors qu’intuitivement il devrait pas, idem. Et je suis également assez sensible à la complexité du compilateur lui-même, du reste.
Je crois qu’on va là refaire le débat séculaire du « worse is better » : http://www.jwz.org/doc/worse-is-better.html :). Et étant clairement du côté worse-is-better, c’est la raison pour laquelle je me méfie de Scala et privilégie Go. Ce n’est pas un hasard si go a tant de succès auprès de suckless & co.
Enfin, je dis ça, mais apprendre Haskell est sur ma TODO-list depuis un moment ;) (plus pour ma culture que pour une réelle utilisation toutefois)
[^] # Re: typage mou
Posté par Moonz . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 2.
Heu, non, en Javascript, x.foo et x["foo"] sont équivalents
[^] # Re: +1
Posté par Moonz . En réponse au journal Wikileaks et OVH : ce qui devait arriver arriva.... Évalué à 2.
[^] # Re: Se tirer une balle dans le pied
Posté par Moonz . En réponse au journal Google: vers un contrôle assumé des résultats. Évalué à 1.
Peut-être bien, mais tant que les autres sont cul-de-jattes (au point de vue de la pertinence des résultats, de la flexibilité d’utilisation, de la légèreté), il lui reste un pied d’avance ;)
[^] # Re: typage mou
Posté par Moonz . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 2.
Et j’ai bien peur que ça finisse comme la métaprogrammation en C++ tout ça…
[^] # Re: typage mou
Posté par Moonz . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 6.
[^] # Re: typage mou
Posté par Moonz . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 6.
func printFloat(f float) {
print(f)
}
func main() {
var x int = 5
printFloat(x)
}
Il vous faut quoi de plus pour que ce soit du typage fort ?
[^] # Re: Mais sinon, pourquoi je devrais m'intéresser à ce énième langage
Posté par Moonz . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 1.
Je crois que tu n’as pas compris leur système d’interfaces. Une même interface est comprise pareille pour tout le monde. Si tu fais un minimum de Go, tu verras par exemple que l’interface Reader est utilisée absolument partout (dans io, http, json, logger,…), et tout le monde la comprend pareil. Idem pour l’interface Error.
> La notion d'interface permet de donner une sémantique à ses méthode
Ben oui, c’est ce que fait une interface en Go ; un ReadWriter, c’est un objet sur lequel on peut lire et écrire.
Ou alors j’ai pas compris ce que tu voulais dire par « donner une sémantique à ses méthodes ».
> et là, justement ce n'est que du structural typing statiquement typé !
En quoi est-ce supposé être en contradiction ?
> avec son typage VRAIMENT avancé (higher-kind et autres trucs du genre)
Par exemple ?
> avec une vraie réflexion sur le lien entre objets et fonctions
Par exemple ?
> (voir tout le travail sur les contraintes sémantiques encodées avec les types pour avoir plus de vérification et de sûreté à la compilation par exemple).
Un lien ?
[^] # Re: typage mou
Posté par Moonz . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 7.
Qu’est-ce que tu entends par là ?
C’est du typage statique, fort, à inférence locale. Je vois pas ce qu’il te faut de plus. C’est l’inférence locale qui te gène ? Pourquoi ?
[^] # Re: Bienvenue
Posté par Moonz . En réponse au journal Google: vers un contrôle assumé des résultats. Évalué à 2.
« liberté », « arbitraire », ce sont des concepts constitutionnels et de philosophie politique, absolument rien à voir avec la choucroute (neutralité d’un acteur privé sur internet).
Si Google viole tes libertés, la manière la plus simple d’y remédier est de porter l’affaire devant la justice.
[^] # Re: Censure?
Posté par Moonz . En réponse au journal Google: vers un contrôle assumé des résultats. Évalué à 2.
Ben porte plainte contre Google alors. Ça aura au moins le mérite de faire rire quelques juristes.
(indice : liberté d’expression ≠ obligation légale de neutralité)
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Ben non, vu le nombre de programmeurs compétents, s’il y avait un besoin (d’IDE), t’inquiète que les IDE se mettraient à pousser comme des champignons et que un ou deux sortiraient vite du lot.
D’ailleurs, tu remarqueras que pour Python par exemple, des IDE de très bonne facture existent [http://eric-ide.python-projects.org/], mais sont peu utilisés.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Allez, encore un petit effort et tu pourras être encore plus insultant.
Bon, comme tu as l’air d’être un peu dur à la compréhension, je répète. Tu me dis :
- Java a de bons IDE => Java est un bon langage (plus exactement, tu as dit : la qualité de ses IDE est une mesure de la qualité d’un langage)
Je te dis: c’est faux, parce que la bonne relation de causalité est:
- Java nécessite un IDE pour être utilisé => Java a de bons IDE
Avec, pour argument : de très bons langages, qui ne nécessitent pas d’IDE, ne donnent pas une telle « culture de l’IDE » : Ruby et Python par exemple. L’immense majorité des devs de RoR sont soit sous vim, soit sous TextMate. Ce se sont incompétents ? Des narcissiques qui préfèrent « se mesurer la quequette » plutôt que d’être productifs ?
C++, qui, au niveau « nécessité de l’utilisation d’un IDE », se situe entre Python et Java, ben se situe également entre les deux sur « qualité des IDE » (refactoring moins bon voire inexistant par exemple) et sur « nombre de programmeurs préférant travailler avec un IDE en C++ »
> mais le but du jeu c'est de produire des applis
Putain, j’aurais jamais deviné tout seul. Merci beaucoup de m’avoir prévenu, heureusement que tu es là.
Maintenant, est-ce qu’il ne te serait pas venu à l’esprit que :
- l’utilisation des IDEs a des avantages mais aussi des inconvénients (naoon, pas possible !)
- le poids de ces avantages et de ces inconvénients diffère selon le langage et même la personne (fou hein !)
- et que donc, au niveau productivité, l’utilisation ou non d’un IDE dépend du langage, du projet, et de la personne (bon, je commence à avoir mal à l’épaule à force d’enfoncer des portes ouvertes)
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
[^] # Re: Banques
Posté par Moonz . En réponse au journal Éloge du don. Évalué à 2.
> si elle est imposé de la même façon qu'un cadre moyen
(H1) en absolu
(H2) en proportionnel
> et que tu trouve cela normal
yep
> et que tu trouve normal que l'impot soit proportionnel à la capacité contributive
yep, avec capacité contributive = revenu
> ca veut donc dire que tu considère que la capacité contributive de Mme bettencourt est identique (en % de sa fortune et/ou revenue) que celle d'un cadre moyen.
Dans le cadre de (H2): ce n’est qu’une reformulation de (H2). Si tu veux dire que (H2) => (H2), pas la peine, je savais depuis un moment (et tes hypothèses intermédiaires ne servent à rien).
Dans le cadre de (H1): ça veut dire que dans mon monde idéal, oui, cette situation implique logiquement que Bettancourt a le même revenu qu’un cadre moyen. Comme ce n’est pas le cas, mon monde idéal n’est pas le monde réel. So what ? Je me répète : je n’avais pas besoin de toi pour m’en rendre compte.
(par ailleurs, 17 milliards, c’est sa fortune, pas son revenu, et en France la base de l’impôt c’est le revenu — sauf pour cet extraterrestre légal qu’est l’ISF)
[^] # Re: re
Posté par Moonz . En réponse au journal Le greffon propriétaire qui éblouit (oui, qui Flashe quoi) évolue. Évalué à 3.
http://www.whatwg.org/specs/web-apps/current-work/#devices
> Quand aux perfs, tenez vous le pour dit: le jour ou les sites vont rajouter de la pub en overlay sur les video, vous allez voir votre cpu remonter aussi haut qu'il le faisait avec flash.
Ben non, quand tu mets des sous-titres avec mplayer sur une vidéo, il ne désactive pas l’accélération matérielle pour autant. C’est donc que tu peux combiner overlay et accélération matérielle.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Ça, ça dépend complètement du langage. Effectivement, l’immense majorité des devs Java aiment les gros IDE, mais c’est exactement parce que le langage est inutilisable sans (forcément, étant donné que les 3/4 du code sont tellement trivial qu’un IDE peut le générer et qu’un être humain se fait chier à en crever à l’écrire…)
Les développeurs Python, Ruby et PHP n’aiment en général pas les IDE parce que ces derniers sont incapables d’utiliser toute la puissance de leur langage (et pourtant, la puissance de PHP…)
Pour les développeurs C et C++, ça dépend franchement des milieux.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
> Sauf que la complétion, les opérations de refactoring, de génération de code et de modélisation ne sont souvent bien implémentées que pour Java. C'est bien dommage d'ailleurs!
Refactoring, peut-être (jamais essayé les outils de refactoring d’eclipse dont on me rebat tant les oreilles), pour le reste, tu as totalement craqué, n’importe quel IDE un tant soit peu complet est capable de faire ça pour le C ou le C++
[^] # Re: Bien obligé non ?
Posté par Moonz . En réponse au journal "J'ai raison, mais je ne ferai pas valider mon raisonnement". Évalué à 4.
C’est vrai, autant qu’ils se règlent à la carabine, ce sera plus calme pour tous les autres voisins ensuite.
> qu'on ne peut résoudre autrement
Raisonnement circulaire. Si deux voisins ont un conflit mais arrivent à s’entendre sur la manière de le résoudre sans faire intervenir la justice, ben par définition ils n’iront pas devant la justice. S’ils n’y sont pas capable, c’est qu’on est pas capable de le résoudre autrement, à moins de rétablir les duels…
> Sinon c'est claquer l'argent du contribuable par les fenêtres.
L’Arbitrage (droit), c’est rendre justice aussi.
[^] # Re: Bien obligé non ?
Posté par Moonz . En réponse au journal "J'ai raison, mais je ne ferai pas valider mon raisonnement". Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Relativement au C, l’écart n’est pas tellement évident sur une machine récente.
(par rapport à du vrai C++ avec des templates de partout, par contre, je suis à 100% d’accord)
> accès concurrents...
Toujours indéfinis en Java, et dans tous les langages que je connais d’ailleurs.
> IDE et outils peu puissants
La plupart des IDE « puissants » sont multi-langage. Quant à des outils puissants, liés au langage, qui auraient contribué au succès de Java, je vois pas.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Il est clair que quelqu’un qui a deux ans de « programmation » (comprendre : un DUT informatique) derrière lui, je le met pas dans un projet en C direct, sauf à mettre quelqu’un qui relit chacune de ses lignes derrière.
[troll]
D’ailleurs, c’est pas ça le principe d’un noob fraîchement diplômé, de se charger du code des projets Java-bateau, pour que les personnes plus expérimentées puissent se concentrer sur de vrais projets ?
[/troll]
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Si C++ interdit la surcharge sur la seule base de la taille d’un type numérique, c’est pas pour rien : c’est très casse-gueule.
Mais bon, je pense (sans ironie) que je ferai mieux de me taire, je connais pas assez le fonctionnement interne des JVM ni même à quoi ressemble le bytecode Java (en dehors que c’est du bytecode).
> Ben en Java c'est pas un hasard.
Dans le sens de coïncidence, pas d’aléatoire.
> La norme Java ne défini pas de type dont le nom comporte le nomber de bits associés.
J’avais oublié ce détail (une des nombreuses raisons que je fuis Java, pourtant… mais si je devais toutes les retenir… mais on s’éloigne du sujet).
Effectivement, je vois pas de meilleure solution que d’encapsuler ça dans une classe et de mettre un commentaire.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
L’API J2** a évoluée, le langage Java a vu des fonctionnalités ajoutées. Par contre, je n’ai pas vu des fonctionnalités du langage modifiées (ce que serait « bon en fait on s’est planté, les long comme indice d’un tableau, c’est valide… J’aimerais bien voir d’ailleurs comment ils feront pour faire cohabiter les programmes dont le bytecode contient des index de tableaux en int et des index de tableaux en long, mais en même temps je connais pas le bytecode Java). Si tu as des exemples…
> C'est absolument pas une hérésie en Java
Si, de la même manière que new int[(int)math.PI] est une hérésie. Pour la n-ième fois, c’est pas parce qu’une constante marche « par hasard » qu’il est correct de l’utiliser. Si le type de ta variable nécessite sémantiquement une taille définie, tu l’explicites, sinon celui qui reprendra le projet dans 5 ans risque de se casser la tête (il voulait juste un nombre ou il voulait un conteneur pour 32 bits ? Je peux utiliser short pour réduire l’emprunte mémoire étant donné que maintenant on stocke des centaines de millions d’éléments ?)
> tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?
Heu, tous les algos de base pour la manipulation des structures de données : tables de hashage, graphes & arbres, liste chainées, tableaux, qui en pratique scalent selon la taille du type de base (pointeur pour les liste chainées, entier pour le tableau,…)
> Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
En quoi c’est ridicule ?
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Ce qui n’est pas en soit surprenant.
> Ca a tout son sens quand ton soft gere 32768
Tu mélanges deux situations différentes. Ton soft gère 32768 éléments ou MAX_INT éléments ? Ce n’est pas la même chose.
Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.
> et on verra regulierement des tables de 2^32 elements
Ha, mais c’est exactement mon argument plus bas, hein !
1. Là où Java est portable dans le sens où il garantit que l’algo aura les mêmes limites partout, là où C est portable dans le sens où l’algo « scale » avec les capacités de la machine.
2. Justement, je suis impatient de voir comment fera Java quand on verra régulièrement des tables de 2^32 éléments, alors qu’il est écrit dans sa spec que l’index d’un tableau, c’est 32 bits.
> Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.
Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.
C’est pas « plus » ou « moins » portable, c’est différent. Pour une FFT fenêtrée de taille fixe sur un stream, l’approche Java est plus adaptée. Pour de la manipulation d’images, l’approche C est plus adaptée (tu aimerais que la limite en taille d’image puisse s’adapter avec l’évolution du matos : images 170 par 170 au max sur du 16 bits, 65000 par 65000).