Ripp-It AM En quel langage ?

Bonjour, j'aimerais savoir en quel langage ripp-it am est-il codé.
Et également savoir quelle interface graphique utilisez vous.
Merci de votre aide, car je connais le C et un peu le C++ mais je ne pense pas qu'il soit codé avec.
Et si sur ce langage vous avez des tutoriels n'ésitez pas.
Merci à vous.

L'interface Ri4m est codée en C

Et le reste ?

Les applis externes en C et Deplhi surement

moi qui croyait rol que c'etait codé en LISP

Salut mon gnou

Comment tu vas ?

Pour LISP, c'est un peu 'has been', maintenant il y a le C# ou le Java

Ca va mon rol,je passe un entretien pour un boulot jeudi.



il faut se méfier des apparences : Orienté objet?

mais c'est sur que c'est pas en lisp que je vais programmer!!

A l'heure actuelle,mon langage préféré est ruby .

d'ailleurs le projet perso de site web que je développe en ce moment est fait avec le framework ruby on rails.

Ca supporte bien la charge le ruby ? Pour le moment, je n'ai rien vu de meilleur que le php pour cela...

C'est pour faire quoi comme taf ton entretien jeudi ?

ruby est un langage lent mais ne bouffe pas au temps de mémoire que java ou c#.
maintenant on peut comparer de 2 façons langage contre langage,ou framework contre framework.
Si tu compares ruby à php, php battrait haut la main ruby puisque la plupart des fonctions de php sont écrites en C, ce qui n'est pas le cas pour ruby.
maintenant si tu compares le framework Ruby On Rail et le clone le plus proche dans ses capacités en PHP symfony,il semble à l'heure actuel que rails soit plus performant,sans doute parceque c'est plus simple d'implementer ceci en ruby qu'en php.
maintenant lorsque tu utilises ce genre de framework quelque soit les langages,tu n'utilises pas non plus des les mêmes solutions que d'habitude pour le serveur web.tu dois obligatoirement le faire tourner en Fastcgi (CGI=>un interpreteur par page,FastCGI=>un interpreteur par utilisateur).
Apache gere tres mal le fastcgi,tu dois utiliser d'autres serveurs comme lighthtppd,ngynx.A l'heure actuelle,la configuration pour ROR qui est à la mode est apache+mongrel(serveur fastcgi ecrit en ruby/c),tu utilises mongrel comme serveur web proxy qui est utilisé pour les taches courantes,et tu passes seulement sur apache pour toutes les taches que mongrel ne sait pas faire.
c'est clair qu'en charge cela doit consommer plus mais lorsque tu connais rails c'est trés difficile de revenir à faire du PHP pur.

pourl'entretien,il s'agit de faire le site du film americain de deauville.

C'est compilé le Ruby ?

En fait, j'ai l'impression que les frameworks ne sont tout simplement pas adaptés à des architectures web chargées

Lighthttpd a l'air d'être une solution interessante niveau serveur. J'ai vu quelques bench et Apache est loin derrière

Cool pour le taf

ruby est interprète à l'heure actuelle.ruby 2.0 possedera une machine virtuelle.les benchmarks annoncent une vitesse 2 à 3 fois plus elevés par rapport à ruby 1.8.
note en ce moment,sun et microsoft sont trés interessé à faire tourner python et ruby sur leurs JVM.Il faut dire qu'en developpement web , ruby et python piquent plus des programmeurs J2EE et ASP.NET que PHP.
je crois que Jruby arrive a faire fonctionner rails sur un serveur tomcat.C'est assez drole puisque le createur de tomcat à arreter java pour devenir consultant ruby on rails .
Si cela continue,on va pouvoir executer php sur une JVM Java ou .NET

Ca fait froid dans le dos!!

Effectivement y a du mouvement

Encore un effet de mode à ton avis ou non ?

les gars qui font jruby et ruby.NET le croivent certainement,ce sont des projets à l'origine qui etaient exterieur à sun et microsoft avant qu'ils les engagent pour qu'ils travaillent à temps complet.
il faut dire que J2EE et ASP.NET marchent bien en intranet.Par contre,sur internet,PHP les a dégommés.De ce point de vue la ,ASP.NET est un echec par rapport à ASP.
c'est plus une reaction defensive pour garder leur part de marche,je doute quand même sur le fait que ruby ou python puissent les detroner mais l'exemple du PHP leur a fait comprendre qu'il fallaient faire attention à la concurrence,on ne sait jamais

Pour un échec, ASP.NET un vrai échec...

Mais j'ai des doutes concernant les percées de Ruby car PHP est bien installé et le langage continue à évoluer

je n'ai jamais dit que ruby allait devenir plus populaire que PHP,je n'y crois pas non plus.
Par contre ,je ne crois pas non plus que le langage PHP puissent devenir aussi bon que ruby.
il faudrait casser la compatibilité avec PHP 4.0,devenir totalement objet et cela je n'y crois pas non plus,il y a trop d'applications PHP non objets,ce saurait faire la même erreur que ASP.NET.Si kro avait fait un ASP amélioré,juste pour combler les manques par rapport a php,PHP aurait une vie bcp plus difficiles mais kro a prefere se battre avec java,le marché des grosses entreprises etant bcp plus rentables.

bon,maintenant petit exercise rol tiré d'un probleme que j'ai résolue pour quelqu'un
tu as 2 tables dans une base de données l'un contient des formules mathematiques qui sont des chaines de caracteres,l'autre table contient des variables avec le nom de la variable qui est une chaine de caractere et sa valeur qui est un numerique.
Apres avoir recupere une formule et ses variables dans la base Comment fait tu pour obtenir en PHP le resultat de la formule?
voila ma solution en ruby 8 lignes formule ruby

C'est vrai que tu es fan d'expressions régulières toi

Sinon, il me semble que PHP 6.0 sera complètement objet

non,PHP6 ne sera pas totalement objet ,ce sera juste une simple évolution de PHP5
nouveautes PHP6
90% des outils de gestion de contenus,des application de forums,et des applications blogs en php ne sont pas écrites en objet et les personnes qui ont développes toutes ses applications ne veulent pas récrire entièrement leur application.Si zend le faisait,il risquerait d'avoir un fork de PHP et cela enlèverait toute crédibilité.

Bizarre je pensais que PHP6 était complètement objet. C'était peut-être en projet puis ils ont abandonné l'idée.

Ceci dit le forum ici ne tourne pas sous PHP5 déjà... il lui faut PHP4 ce qui n'est pas bien pratique.

la plupart des hebergeurs te laisse le choix ,ce qui prouve que php 5 ne sait pas non plus trop imposé.
je crois aussi que php6 risque de prendre le même chemin ,il y a des chose trés discutables dans php6.

sinon,a par ca j'ai passe mon entretien.