L'idée ce n'est pas de lancer un concours, mais pour les langages où il y a plusieurs versions, comment imaginez vous le différencier pour l'utilisateur final ? TapTempo-Closure1 vs. TapTempo-Closure2 ?
Peut-on facilement être inclus dans l'organisation GitHub, en tant que développeur ayant partagé sa version de TapTempo ?
Doit-on aussi donner un nom spécifique à chaque version, pour que les gens s'y retrouvent ? Par exemple j'aimerais bien pouvoir distribuer le mien comme étant la variante PhapTempo (en honneur à PHP).
Cependant elles sont toutes open source, non dans le sens libre du terme, mais dans le sens ou le code est accessible librement et sa lecture est gratuite et sans conditions.
On parle toujours de développement là ? A priori, ça arrive rarement de développer sur une machine de production ou de l'autre côté de la planète non ? Où alors ça peut j'imagine, mais c'est carrément se tirer une balle dans le pied.
Il y a bien sûr quelques exceptions, comme par hasard le développement sur SAP, mais de toute façon là tu oublie le SSH puisque t'es obligé de passer par leur environnement de développement propriétaire, ou le développement sur certains vieux mainframes, mais c'est très spécifique.
Je travaille avec des VM de dev depuis plusieurs années, et l'avantage d'une VM locale dans ta propre machine, c'est que tu peux monter facilement un partage de fichier, un NFS ou autre SSHFS (nous on utilise SSHFS après avoir expérimenté NFS, j'ai encore des vieilles VM en NFS par ailleurs) et on utilise les outils de développements de la machine hôte pour le projet dans la VM sur le point de montage de la VM.
Plein de gens pensent que le SSHFS est lent, mais que nenni, en vrai j'ai un Eclipse branché dessus, et la différence ne se voit pas (un autre avantage des IDE de manière générale est leur bonne gestion du FS, l'indexation efficace, bien que tous ne soient pas égaux la dessus).
Le mieux du mieux c'est qu'en tant que développeur, je n'ai pas à m'occuper de comment ça marche puisqu'on a un outillage interne qui effectue le déploiement sur nos machines, quelle soit la distribution Linux (et fonctionne aussi avec MacOS). Encore une fois, VIeMacs dans un SSH n'a absolument pas sa place dans cette infra.
Je tiens à préciser que nos VM peuvent par ailleurs contenir des Docker, et de manière générale sont ISO-prod, contiennent les mêmes outils de déploiement, seul leur dimensionnement (nombre de CPU et RAM) change.
Je me demande surtout pourquoi tu as mis toutes tes méthodes et propriétés et "static", ça n'a pas de sens: dans ce cas là écrit juste des fonctions, sachant que l'utilisation de namespaces fournit le seul avantage qu'une classe entièrement statique peut t'apporter (c'est à dire grouper dans un même espace de nom tes propriétés et méthodes).
Après, dans la pratique, dans ce code en particulier c'est pas grave, mais le fait que tout soit statique de manière générale induit un global state, qu'on essaye de toujours éviter car dans un projet plus complexe, ça augmente la surface de potentiels effets de bord, et va plutôt dans le sens inverse de l'immutabilité.
Avec un vrai accompagnement depuis la seconde on pourrait formaliser le choix de l'élève bien avant la date limite des dépôts.
Oui je suis tout à fait d'accord avec ça, c'est que j'entendais en parlant de besoin d'accompagnement. Là on commence à attaquer un sujet politique beaucoup plus profond que simplement le logiciel admission post-bac. Sans aller plus loin dans le débat parce qu'à mon opinion c'est pas le bon endroit pour, je trouve que c'est une honte la façon dont les (au moins 4, donc l'actuel) derniers gouvernements ont laissé tombé les jeunes et l'éducation.
Quand j'ai passé mon bac, j'ai du inscrire mes voeux sur un minitel, et on avait des plages de date qui nous étaient imposés par l'administration de notre lycée, du coup les inscriptions (du moins au sein de notre lycée) étaient lissées sur plusieurs jours pour l'ensemble des élèves de terminale.
Je ne comprends pas qu'on laisse tous ces gamins (ce n'est pas péjoratif, loin de là, je l'ai été moi aussi - c'est dans le sens qu'ils ont probablement besoin d'accompagnement même si la plupart sont déjà légalement adultes) faire ça à leur convenance au moment qu'ils veulent: sachant qu'ils sont censé y avoir réfléchit (au parcours qu'ils souhaitent faire) depuis des mois et des mois, l'inscription sur le service n'est en elle même qu'une formalité, c'est le choix qui est difficile, et en ce sens, ils auraient du prendre leur décision bien avant.
Le problème, c'est que je ne connais aucun IDE qui s'intègre à mon shell aussi bien qu'un éditeur de texte du type vi (s'applique aussi à emacs, pour le coup je suppose).
Mais bon, oui, pour ceux qui aiment aller chercher la souris, les IDEs modernes sont superbes. J'en ai utilisés, j'ai même commencé par ça.
Pour l'intégration au shell, certes, mais du point d'un développeur d'applications, et non juste d'un simple besoin d'éditer du texte sur un serveur, ça n'a que peu d'intérêt, car finalement le shell n'est lui même, pour beaucoup de développeurs, qu'une interface pour lancer d'autres commandes (utiliser outillage dont je parle en somme), et s'il est intégré dans un logiciel spécifique, le shell n'a plus réellement d'utilité pour beaucoup de gens.
L'automatisation que te fournit ton outil de développement intégré (IDE en toutes lettre pour recentrer le contexte) va, en avance de phase, ordonnancer tout ces outils de manière cohérente selon les technologies que tu utilises, et pour certains tout en restant extrêmement flexibles et configurables, pour ne pas t'enfermer dans les choix d'opinion du développeur de ce dernier.
Toute cette automatisation qu'il prend en charge d'entrée de jeu et sans devoir y installer des dizaines de plugins, ni taper des centaines de lignes de configuration dans dot file, sans même avoir besoin d'en connaître les raccourcis claviers, permet à la fin d'avoir un environnement ISO sur tous les postes de travail sur lequel un développer peut être performant extrêmement rapidement, tout en restant configurable pour ceux qui veulent aller plus loin.
La plupart sont tous aussi automatisables que Vi ou Emacs eux-même, fournissent des débuggeurs contextuels, graphiques et lisibles, des possibilités d'introspection du code puissante et par simple clic, un retour visuel des erreur au fil des actions du développeurs, une UI qui se contextualise en fonction des actions menés, une interface multi-éditeur en onglet, ou pavable, etc, etc, etc.. Ce qui de prime abord, pour réussir à mimer de façon complète dans un Vi ou un Emacs demande un courbe d'apprentissage extrêmement complexe: les gens qui maîtrisent et utilisent quotidiennement ces deux derniers ont tendance à l'oublier.
Ah, et aussi, pas besoin d'interface graphique, DONC utilisable via ssh
Quelle idée de travailler via SSH ! Enfin encore une fois du point de vue d'un développeur, ça n'a pas de sens. Si j'ai une machine sous les doigts, je n'ai pas besoin d'une deuxième pour développer, celle que j'ai me suffit, et ce même si ma cible est un environnement radicalement différent, c'est une autre des forces de l'IDE, de pouvoir émuler ce dernier sans avoir besoin d'y redéployer du code en permanence.
On pourrait avoir le même genre de discours à propos de vim, aujourd'hui les IDE apportent tellement de fonctionnalités, et sont tellement bien intégrés avec les différents outillages que ça devient difficile de continuer à faire de la pub pour les bons vieux éditeurs pour doigts magiques.
Je suis bien d'accord avec toi en ce qui concerne le Rust. Go gagne énormément en popularité, je regarde un peu de temps en temps la doc et j'en lis pas mal de code, et je pense que sa simplicité et son efficacité lui font gagner des points. Cependant j'ai lu pas mal d'article qui exposent ses faiblesses, et qu'apparemment, Go c'est pas si bien que ça (apparemment il a quelques ambiguïtés, je peux pas trop juger j'en ai pas fait moi même ceci étant dit). Rust a une syntaxe qui lui est propre (je connais pas de langage qui lui ressemble) et semble un peu compliqué de prime abord, j'ai tapé des hello world ou choses du genre, c'est assez surprenant au départ, mais les promesses qu'il donne quand au zero-cost abstraction et à la memory safety semble vraiment intéresser de plus en plus de gens.
J'ai toujours trouvé ça super étonnant, au vu des problèmes de performance que j'ai eu (sur plusieurs postes, Windows comme Linux) sur des gros projets: des freeze pouvant aller jusqu'à freezer toute la machine (sur Windows surtout) - et le manque de fonctionnalités sur pas mal de langages (à cause du manque de plugins corrects souvent).
Vu que je travaille dans le web, je fais la ronde des langages, mais non pas au fil des ans, mais au fil des heures, avec son lot d'immaturité et déconvenue, le monde du web me tuera.
Mon expertise: Java (anciennement), PHP (depuis des années)
À côté, mais nécessaire: *SQL (si si c'est un langage à part entière)
Obligé à cause des autres (TM): TypeScript, JavaScript
De mon plein gré sur mon temps perso: Java, PHP, Python, C#
Et j'en oublie sûrement, je suis amené parfois à intervenir sur toutes sortes de projets, toujours dans le web. Et les stacks sont tellement compliquées que de toute façon, c'est impossible sans être polyglotte.
À noter que j'ai joué avec C, C++ et Rust aussi, mais à des fins de tests (notamment pour comparer le bytecode généré par les 3) - mais je n'ai pas un niveau assez élevé avec aucun de ces 3 là pour réellement pouvoir en profiter.
Côté goûts:
Je hais: le C, le JavaScript, le Python, et tous les autres langages à typage dynamique (je sais, le C n'en est pas, mais le C est dangereux pour la santé), et encore plus ceux où le monkey patch est possible (franchement, pour tous les adorateurs de Python, désolé, mais c'est plus proche de JavaScript qu'aucun autre langage, mais on en parlera plus tard),
J'adore: le Rust, le PHP (c'est un biais, ça reste un langage de merde), le Java, le C#, et tous les langages à typage statique (bien que PHP moderne jouisse d'un typage fort, mais pas complètement statique car les checks sont au runtime, saloperie),
Je vois que tu as fais le choix d'écrire le code sous la forme d'une classique avec que des méthodes statiques: dans l'absolu, le code est plus rapide écrit de cette façon, mais d'un autre côté, ça rend toutes les variables de ton code globales par définition, et donc non testable et sujet à effet de bord.
La mode dans le PHP actuel (sauf avec Laravel, qui à mon sens n'est pas un framework mais une blague, attention, troll detected) c'est plutôt d'essayer d'aller vers l'immutabilité et de se rapprocher du fonctionnel (pour avoir le moins d'effets de bord possible et améliorer la testabilité du code).
Ça reste bien entendu très théorique et religieux tout ça.
Le soucis avec l'entrée standard en PHP, c'est que tant que tu n'as pas de line feed, les fonctions de lecture du flux ne te donnent rien. Je t'avoue que je n'ai pas réellement pris le temps de chercher pourquoi la réponse est dans le commentaire lié plus haut: stty -icanon désactive le buffering de STDIN, j'image qu'il est bufferisé pour des raisons de performance à l'origine (quand on lit le thread Stack Overflow là: https://stackoverflow.com/questions/3684367/php-cli-how-to-read-a-single-character-of-input-from-the-tty-without-waiting-f/3684565#3684565 on se rend compte que c'est bien dans le cas des remote terminals). Dans l'absolu, fread() et stream_get_contents() ici sont équivalents (j'ai testé les deux).
J'ai vu que sur archlinux, il y a package sur AUR - j'ai essayé de l'installer, malheureusement il nécessite tout de même qu'on installe l'Android SDK - est-ce possible de s'en sortir sans facilement en prenant le jar déjà compilé ?
Perso j'utilise Eclipse pour PHP, avec PDT et les PDT Extensions du PDT Extension Group - je suis presque (je dis presque, il manque deux trois petites choses) on-par avec PHPStorm.
Il n'y a aucun autre IDE Open Source qui arrive à un tel niveau de fonctionnalités qu'Eclipse, que ce soit pour PHP ou tant qu'IDE multi-languages.
Pour tout ceux qui pensent qu'Eclipse est une usine à gaz lente, ça fait des années que ce n'est plus vrai - ça marche très bien aujourd'hui. Comparativement avec PHPStorm que pas mal de mes collègues utilisent (attention, je ne troll pas, c'est un excellent produit) il y a pas mal de scénarios ou Eclipse est plus stable et plus rapide:
très gros projets sur du SSHfs: Eclipse indexe plus rapidement que PHPStorm (parfois même sans le SSHfs tout court),
debuggueur XDebug (toujours PHP) sur un système de fichier avec des chemins bizarres et autres liens symboliques: Eclipse ne perd quasiment jamais le contexte là ou PHPStorm parfois n'arrive pas (du tout) à retrouver la source et ne peut lancer les sessions de debug.
Voilà voilà, je tiens à défendre Eclipse car contrairement à cet espèce de mythe infâme que j'entends partout, il n'est pas plus lent que pas mal d'autres produits. Et il est extrêmement fonctionnel (de plus très configurable).
[^] # Re: ...
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Naissance de la Taptempo-Federation. Évalué à 2.
Ça dépasse tout ce que j'avais pu imaginer.
[^] # Re: Questions
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Naissance de la Taptempo-Federation. Évalué à 2.
L'idée ce n'est pas de lancer un concours, mais pour les langages où il y a plusieurs versions, comment imaginez vous le différencier pour l'utilisateur final ? TapTempo-Closure1 vs. TapTempo-Closure2 ?
# Questions
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Naissance de la Taptempo-Federation. Évalué à 3.
Peut-on facilement être inclus dans l'organisation GitHub, en tant que développeur ayant partagé sa version de TapTempo ?
Doit-on aussi donner un nom spécifique à chaque version, pour que les gens s'y retrouvent ? Par exemple j'aimerais bien pouvoir distribuer le mien comme étant la variante PhapTempo (en honneur à PHP).
# Oui, mais open source tout de même
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Le vrai problème avec toutes ces ré-implémentations de TapTempo c'est .... Évalué à -6.
Cependant elles sont toutes open source, non dans le sens libre du terme, mais dans le sens ou le code est accessible librement et sa lecture est gratuite et sans conditions.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Le débat est clos. Évalué à 2.
On parle toujours de développement là ? A priori, ça arrive rarement de développer sur une machine de production ou de l'autre côté de la planète non ? Où alors ça peut j'imagine, mais c'est carrément se tirer une balle dans le pied.
Il y a bien sûr quelques exceptions, comme par hasard le développement sur SAP, mais de toute façon là tu oublie le SSH puisque t'es obligé de passer par leur environnement de développement propriétaire, ou le développement sur certains vieux mainframes, mais c'est très spécifique.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Le débat est clos. Évalué à 2. Dernière modification le 15 mars 2018 à 09:46.
Je travaille avec des VM de dev depuis plusieurs années, et l'avantage d'une VM locale dans ta propre machine, c'est que tu peux monter facilement un partage de fichier, un NFS ou autre SSHFS (nous on utilise SSHFS après avoir expérimenté NFS, j'ai encore des vieilles VM en NFS par ailleurs) et on utilise les outils de développements de la machine hôte pour le projet dans la VM sur le point de montage de la VM.
Plein de gens pensent que le SSHFS est lent, mais que nenni, en vrai j'ai un Eclipse branché dessus, et la différence ne se voit pas (un autre avantage des IDE de manière générale est leur bonne gestion du FS, l'indexation efficace, bien que tous ne soient pas égaux la dessus).
Le mieux du mieux c'est qu'en tant que développeur, je n'ai pas à m'occuper de comment ça marche puisqu'on a un outillage interne qui effectue le déploiement sur nos machines, quelle soit la distribution Linux (et fonctionne aussi avec MacOS). Encore une fois, VIeMacs dans un SSH n'a absolument pas sa place dans cette infra.
Je tiens à préciser que nos VM peuvent par ailleurs contenir des Docker, et de manière générale sont ISO-prod, contiennent les mêmes outils de déploiement, seul leur dimensionnement (nombre de CPU et RAM) change.
[^] # Re: Static ! Ouate !
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Portage de TapTempo en PHP. Évalué à 2.
Je me demande surtout pourquoi tu as mis toutes tes méthodes et propriétés et "static", ça n'a pas de sens: dans ce cas là écrit juste des fonctions, sachant que l'utilisation de namespaces fournit le seul avantage qu'une classe entièrement statique peut t'apporter (c'est à dire grouper dans un même espace de nom tes propriétés et méthodes).
Après, dans la pratique, dans ce code en particulier c'est pas grave, mais le fait que tout soit statique de manière générale induit un global state, qu'on essaye de toujours éviter car dans un projet plus complexe, ça augmente la surface de potentiels effets de bord, et va plutôt dans le sens inverse de l'immutabilité.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Le débat est clos. Évalué à 0.
Et bien au contraire, j'aime bien utiliser ma souris. Ça me force à ne pas taper trop vite, et évite de faire certaines erreurs très bêtes.
[^] # Re: Prévisible
Posté par Christie Poutrelle (site web personnel) . En réponse au journal v'la ce qui se passe quand on est pas cloud ready. Évalué à 2.
Oui je suis tout à fait d'accord avec ça, c'est que j'entendais en parlant de besoin d'accompagnement. Là on commence à attaquer un sujet politique beaucoup plus profond que simplement le logiciel admission post-bac. Sans aller plus loin dans le débat parce qu'à mon opinion c'est pas le bon endroit pour, je trouve que c'est une honte la façon dont les (au moins 4, donc l'actuel) derniers gouvernements ont laissé tombé les jeunes et l'éducation.
[^] # Re: Prévisible
Posté par Christie Poutrelle (site web personnel) . En réponse au journal v'la ce qui se passe quand on est pas cloud ready. Évalué à 4. Dernière modification le 14 mars 2018 à 10:14.
Quand j'ai passé mon bac, j'ai du inscrire mes voeux sur un minitel, et on avait des plages de date qui nous étaient imposés par l'administration de notre lycée, du coup les inscriptions (du moins au sein de notre lycée) étaient lissées sur plusieurs jours pour l'ensemble des élèves de terminale.
Je ne comprends pas qu'on laisse tous ces gamins (ce n'est pas péjoratif, loin de là, je l'ai été moi aussi - c'est dans le sens qu'ils ont probablement besoin d'accompagnement même si la plupart sont déjà légalement adultes) faire ça à leur convenance au moment qu'ils veulent: sachant qu'ils sont censé y avoir réfléchit (au parcours qu'ils souhaitent faire) depuis des mois et des mois, l'inscription sur le service n'est en elle même qu'une formalité, c'est le choix qui est difficile, et en ce sens, ils auraient du prendre leur décision bien avant.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Le débat est clos. Évalué à 2.
Pour l'intégration au shell, certes, mais du point d'un développeur d'applications, et non juste d'un simple besoin d'éditer du texte sur un serveur, ça n'a que peu d'intérêt, car finalement le shell n'est lui même, pour beaucoup de développeurs, qu'une interface pour lancer d'autres commandes (utiliser outillage dont je parle en somme), et s'il est intégré dans un logiciel spécifique, le shell n'a plus réellement d'utilité pour beaucoup de gens.
L'automatisation que te fournit ton outil de développement intégré (IDE en toutes lettre pour recentrer le contexte) va, en avance de phase, ordonnancer tout ces outils de manière cohérente selon les technologies que tu utilises, et pour certains tout en restant extrêmement flexibles et configurables, pour ne pas t'enfermer dans les choix d'opinion du développeur de ce dernier.
Toute cette automatisation qu'il prend en charge d'entrée de jeu et sans devoir y installer des dizaines de plugins, ni taper des centaines de lignes de configuration dans dot file, sans même avoir besoin d'en connaître les raccourcis claviers, permet à la fin d'avoir un environnement ISO sur tous les postes de travail sur lequel un développer peut être performant extrêmement rapidement, tout en restant configurable pour ceux qui veulent aller plus loin.
La plupart sont tous aussi automatisables que Vi ou Emacs eux-même, fournissent des débuggeurs contextuels, graphiques et lisibles, des possibilités d'introspection du code puissante et par simple clic, un retour visuel des erreur au fil des actions du développeurs, une UI qui se contextualise en fonction des actions menés, une interface multi-éditeur en onglet, ou pavable, etc, etc, etc.. Ce qui de prime abord, pour réussir à mimer de façon complète dans un Vi ou un Emacs demande un courbe d'apprentissage extrêmement complexe: les gens qui maîtrisent et utilisent quotidiennement ces deux derniers ont tendance à l'oublier.
Quelle idée de travailler via SSH ! Enfin encore une fois du point de vue d'un développeur, ça n'a pas de sens. Si j'ai une machine sous les doigts, je n'ai pas besoin d'une deuxième pour développer, celle que j'ai me suffit, et ce même si ma cible est un environnement radicalement différent, c'est une autre des forces de l'IDE, de pouvoir émuler ce dernier sans avoir besoin d'y redéployer du code en permanence.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Le débat est clos. Évalué à 3.
On pourrait avoir le même genre de discours à propos de vim, aujourd'hui les IDE apportent tellement de fonctionnalités, et sont tellement bien intégrés avec les différents outillages que ça devient difficile de continuer à faire de la pub pour les bons vieux éditeurs pour doigts magiques.
[^] # Re: VSC
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Le débat est clos. Évalué à 5.
Ah c'est malin ça ! Au moins Eclipse il sait faire des trucs :)
[^] # Re: Go ou Rust côté backend, système ou embarqué
Posté par Christie Poutrelle (site web personnel) . En réponse au journal La ronde (boucle?) des langages. Évalué à 4. Dernière modification le 13 mars 2018 à 16:05.
Je suis bien d'accord avec toi en ce qui concerne le Rust. Go gagne énormément en popularité, je regarde un peu de temps en temps la doc et j'en lis pas mal de code, et je pense que sa simplicité et son efficacité lui font gagner des points. Cependant j'ai lu pas mal d'article qui exposent ses faiblesses, et qu'apparemment, Go c'est pas si bien que ça (apparemment il a quelques ambiguïtés, je peux pas trop juger j'en ai pas fait moi même ceci étant dit). Rust a une syntaxe qui lui est propre (je connais pas de langage qui lui ressemble) et semble un peu compliqué de prime abord, j'ai tapé des hello world ou choses du genre, c'est assez surprenant au départ, mais les promesses qu'il donne quand au zero-cost abstraction et à la memory safety semble vraiment intéresser de plus en plus de gens.
[^] # Re: VSC
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Le débat est clos. Évalué à 2.
J'ai toujours trouvé ça super étonnant, au vu des problèmes de performance que j'ai eu (sur plusieurs postes, Windows comme Linux) sur des gros projets: des freeze pouvant aller jusqu'à freezer toute la machine (sur Windows surtout) - et le manque de fonctionnalités sur pas mal de langages (à cause du manque de plugins corrects souvent).
# Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Le débat est clos. Évalué à 6.
Eclipse 18.9%
PHPStorm 9.0%
Emacs 4.1%
Emacs est en dessous de PHPStorm, réveillez vous :D
# Le web, mon ami
Posté par Christie Poutrelle (site web personnel) . En réponse au journal La ronde (boucle?) des langages. Évalué à 8. Dernière modification le 13 mars 2018 à 15:11.
Vu que je travaille dans le web, je fais la ronde des langages, mais non pas au fil des ans, mais au fil des heures, avec son lot d'immaturité et déconvenue, le monde du web me tuera.
Et j'en oublie sûrement, je suis amené parfois à intervenir sur toutes sortes de projets, toujours dans le web. Et les stacks sont tellement compliquées que de toute façon, c'est impossible sans être polyglotte.
À noter que j'ai joué avec C, C++ et Rust aussi, mais à des fins de tests (notamment pour comparer le bytecode généré par les 3) - mais je n'ai pas un niveau assez élevé avec aucun de ces 3 là pour réellement pouvoir en profiter.
Côté goûts:
[^] # Re: Shame on you.
Posté par Christie Poutrelle (site web personnel) . En réponse au journal TapTempo en PHP. Évalué à 2.
Je t'ai reconnu, monsieur Delphi.
# Static ! Ouate !
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Portage de TapTempo en PHP. Évalué à 1. Dernière modification le 13 mars 2018 à 09:17.
Je vois que tu as fais le choix d'écrire le code sous la forme d'une classique avec que des méthodes statiques: dans l'absolu, le code est plus rapide écrit de cette façon, mais d'un autre côté, ça rend toutes les variables de ton code globales par définition, et donc non testable et sujet à effet de bord.
La mode dans le PHP actuel (sauf avec Laravel, qui à mon sens n'est pas un framework mais une blague, attention, troll detected) c'est plutôt d'essayer d'aller vers l'immutabilité et de se rapprocher du fonctionnel (pour avoir le moins d'effets de bord possible et améliorer la testabilité du code).
Ça reste bien entendu très théorique et religieux tout ça.
[^] # Re: Ou pas
Posté par Christie Poutrelle (site web personnel) . En réponse au journal TapTempo en PHP. Évalué à 2. Dernière modification le 13 mars 2018 à 09:12.
Le soucis avec l'entrée standard en PHP, c'est que tant que tu n'as pas de line feed, les fonctions de lecture du flux ne te donnent rien. Je t'avoue que
je n'ai pas réellement pris le temps de chercher pourquoila réponse est dans le commentaire lié plus haut:stty -icanon
désactive le buffering de STDIN, j'image qu'il est bufferisé pour des raisons de performance à l'origine (quand on lit le thread Stack Overflow là: https://stackoverflow.com/questions/3684367/php-cli-how-to-read-a-single-character-of-input-from-the-tty-without-waiting-f/3684565#3684565 on se rend compte que c'est bien dans le cas des remote terminals). Dans l'absolu, fread() et stream_get_contents() ici sont équivalents (j'ai testé les deux).[^] # Re: Ou pas
Posté par Christie Poutrelle (site web personnel) . En réponse au journal TapTempo en PHP. Évalué à 2. Dernière modification le 13 mars 2018 à 09:11.
En théorie c'est facile de faire du PHP sans fuite mémoire, faut éviter les static et les global (EDIT: et fgets apparament).
Oui en effet, j'ai pas pris le temps de donner un peu d'amour à ce code !
[^] # Re: Ou pas
Posté par Christie Poutrelle (site web personnel) . En réponse au journal TapTempo en PHP. Évalué à 2.
Ah c'est marrant, je suis pourtant remonté dans mon historique je l'avais pas trouvé !
# Oups
Posté par Christie Poutrelle (site web personnel) . En réponse au journal TapTempo en emacs lisp. Évalué à 3.
Dans mon Eclipse, ça ne marche pas. Tu mens!
# Et sans le SDK android ?
Posté par Christie Poutrelle (site web personnel) . En réponse au journal scrcpy, une appli pour afficher et contrôler des devices Android. Évalué à 2.
J'ai vu que sur archlinux, il y a package sur AUR - j'ai essayé de l'installer, malheureusement il nécessite tout de même qu'on installe l'Android SDK - est-ce possible de s'en sortir sans facilement en prenant le jar déjà compilé ?
[^] # Re: A peu près pareil que le top
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Quel IDE pour quel langage. Évalué à 4. Dernière modification le 16 février 2018 à 17:02.
Perso j'utilise Eclipse pour PHP, avec PDT et les PDT Extensions du PDT Extension Group - je suis presque (je dis presque, il manque deux trois petites choses) on-par avec PHPStorm.
Il n'y a aucun autre IDE Open Source qui arrive à un tel niveau de fonctionnalités qu'Eclipse, que ce soit pour PHP ou tant qu'IDE multi-languages.
Pour tout ceux qui pensent qu'Eclipse est une usine à gaz lente, ça fait des années que ce n'est plus vrai - ça marche très bien aujourd'hui. Comparativement avec PHPStorm que pas mal de mes collègues utilisent (attention, je ne troll pas, c'est un excellent produit) il y a pas mal de scénarios ou Eclipse est plus stable et plus rapide:
Voilà voilà, je tiens à défendre Eclipse car contrairement à cet espèce de mythe infâme que j'entends partout, il n'est pas plus lent que pas mal d'autres produits. Et il est extrêmement fonctionnel (de plus très configurable).