Welche Sprache soll ich nehmen?
-
Ich meine nicht das Ruby on Rails eine schlechte sprache ist.
Ruby on Rails ist keine Sprache, sonder ein Framework.
Ruby ist die Sprache.
-
Shade Of Mine schrieb:
Solche Sachen sind halt mit Zend genial zu machen - da alles schoen decoupled ist. Wenn man aber sowas nicht braucht, ist ein Alles-Aus-Einem-Guss wie bei Symfony, Rails, etc. einfach besser.
Wobei man sagen muss, dass sich das Tauschen einzelner Komponenten mit Rails 3 ebenfall deutlich vereinfacht hat.
-
Pikkolini schrieb:
Mir fiel sofort ASP.NET mit C# ins Auge, da es angeblich schneller als PHP und Co sein soll und auch das Framework sehr überzeugend ist. Zudem möchte ich auch einen schnellen Datenbank zugriff, was laut google auch damit möglich ist. Allerdings läuft das ganze nur auf Microsoft Servern, was die kosten mir viel zu sehr steigert, wenn ich irgendwann mal z.B. meinen eigenen Server aufstellen will.
Ähhnee, warum stellt das denn keiner richtig?
Für ASP.NET gibt es ein Apache-Modul. Du bist nicht an Windows und IIS gebunden.
-
Ich habe Jahrelang mit Eclipse und den ganzen Plugins gearbeitet und mir auch zum Schluß Aptana installiert. Netbeans hatte ich dann mal aus Jux installiert und bin sofort dabei geblieben, so einfach und übersichtlich dafür musste ich in Eclipse schon viel konfigurieren um an die Funktionalität ranzukommen.
Also für PHP mein absoluter Favorit Netbeans.
-
Hallo, wie steht es denn hier um Perl? Diese Programmiersprach, serverseiti, wurde hier noch nicht genannt.
Warum nicht?
-
Nimm PHP am besten mit dem Zend-Framework und wenn du ganz komfortable debuggen willst dann mit Zend-Studio.
Die meisten C++ler hier haben nicht den geringsten schimmer von PHP und glauben irgendwelchen Tatsachen die, keine Ahnung, 10 Jahre oder so alt sind.
Mit OOP, Namespaces, Execptions und guten Frameworks kann man mit PHP sehr große Projekte auch in Teams wunderbar hochziehen. Die Performance lässt durch Zend-Optimizer etc. noch weiter steigern.
PHP ist ein de facto Standard wo du für dein Team auch immer wieder gute Mitarbeiter findest. Viel Literatur und eine große Community(Nicht nur ein zwei Foren) sind auch immer noch Anzeichen für einen etablierten Standard. Ohne gute PHP-Kenntnisse sollte sich heute keiner mehr Programmierer(Web) nennen dürfen.
-
ie meisten C++ler hier haben nicht den geringsten schimmer von PHP und glauben irgendwelchen Tatsachen die, keine Ahnung, 10 Jahre oder so alt sind.
ich kenne kaum eine
ich selbst arbeite mit zend framework und netbeans, die zwei zusammen ergeben für mich eine optimale arbeitsumgebung, wie MSVS 2010 ultimativ + wxWidgets + Qt + boost + weitere bibliotheken
Eclipse hab ich noch nie probiert da ich mit netbeans 100% zufrieden bin, daher kann ich meine meinung dazu nicht
äußern.
-
phpstandard schrieb:
Nimm PHP am besten mit dem Zend-Framework und wenn du ganz komfortable debuggen willst dann mit Zend-Studio.
Die meisten C++ler hier haben nicht den geringsten schimmer von PHP und glauben irgendwelchen Tatsachen die, keine Ahnung, 10 Jahre oder so alt sind.
Mit OOP, Namespaces, Execptions und guten Frameworks kann man mit PHP sehr große Projekte auch in Teams wunderbar hochziehen. Die Performance lässt durch Zend-Optimizer etc. noch weiter steigern.
PHP ist ein de facto Standard wo du für dein Team auch immer wieder gute Mitarbeiter findest. Viel Literatur und eine große Community(Nicht nur ein zwei Foren) sind auch immer noch Anzeichen für einen etablierten Standard. Ohne gute PHP-Kenntnisse sollte sich heute keiner mehr Programmierer(Web) nennen dürfen.
PHP ist die hässlichste existente Programmiersprache, langsam und inkonsistent durch und durch. Noch dazu einige Bugs. PHP hat den Tod verdient, Gott sei Dank bestätigt der Tiobe-Index das. Der Erfinder von PHP war wohl zu blöd, Variablen von anderen Namen zu unterscheiden und meinte deshalb, sie müssen mit einem $ beginnen - Augenkrebs.
Fürs Web würde ich eindeutig auf Python setzen. Python ist eine moderne Sprache, die einigermaßen schnell ist und dazu eine angenehme Syntax hat.
Die Entwicklungszeiten sind niedrig und es gibt kaum Bugs im Interpreter. Python kann außerdem nicht nur als Websprache eingesetzt werden, sondern auch lokal für Programme verwendet werden.
-
Kann man das Thema nicht schließen? Es nervt so langsam!
Mittlerweile hat auch der letzte verstanden, dass es unterschiedliche Meinungen zu diversen Programmiersprachen gibt.
LG
-
hmmz|off schrieb:
Kann man das Thema nicht schließen? Es nervt so langsam!
Mittlerweile hat auch der letzte verstanden, dass es unterschiedliche Meinungen zu diversen Programmiersprachen gibt.
LG
Klar. Es führt aber kein Weg an HTML und CSS vorbei. Bevor man da nicht
sattelfest ist, ist die Serverseite zweitrangig. PHP ist mir zu lahm, ich
nehme halt etwas anderes.
-
nman schrieb:
Die Ausführungsgeschwindigkeit der Sprache wird für die Performance einer Webanwendung in der realen Welt kaum je in irgendeiner Form einen Flaschenhals darstellen...
und wo verbringt man die meißte zeit? ich dachte, wenn man nicht den teufel raus cached am ehesten in der scriptsprache, oder?
-
Na ja, Dein Script erstellt irgendwie HTML/CSS/JS-Output.
Der wird dann in handliche Häppchen verteilt und dem Apatsche in die
Hand gedrückt. Der sagt dann dem bösen Internet (vdLeyen) "hier, tu das
man dem x.x.x.x irgendwie senden". Dann spastelen sich BND, NSA und wen's
sonst nch interessiert durch die Häppchen, schauen nach ob es was mit
Taliban oder KiPo ist und wenn das Häppchen dann im Browser landet, soll
er sinnvoll damit etwas anfangen und es auf der lahmen Gurke anzeigen.Sorgen um die Laufzeit des Script muß man sich erst bei heftigen Datenmengen
oder richtig großen Portalen machen ...Was man als CGI nimmt ist eigentlich wurscht, ich nehme halt C.
-
Scheppertreiber schrieb:
...soll er sinnvoll damit etwas anfangen und es auf der lahmen Gurke anzeigen...
stimmt! hätte ich fast vergessen, die anzeige braucht natürlich idr. am meisten. aber das ist client und nicht server
p.s. evtl. können wir ja mal zusammen an einer kleinen c-webapp basteln, davon träum ich schon ewig
-
Ich habe ein große Webapp in C ...
-
ja, apache hab ich auch schon drauf :p
-
_-- schrieb:
ja, apache hab ich auch schon drauf :p
Dann bring ihm bei, daß er *.exe (bei Windos) als CGI-Programm behandeln soll.
Der Input (das CGI) kommt über stdin, der Output geht nach stdout.Das Primitiv-Helloworld sieht dann in etwa so aus:
printf( "\n<p>Hello World !</p>");
-
Scheppertreiber schrieb:
Sorgen um die Laufzeit des Script muß man sich erst bei heftigen Datenmengen
oder richtig großen Portalen machen ...Nein. Was wichtig ist ist die Skalierbarkeit. Alles andere ist ziemlich uninteressant.
Was man als CGI nimmt ist eigentlich wurscht, ich nehme halt C.
CGI skaliert absolut beschissen. Man sollte immer als Modul des Webservers laufen.
Deshalb ist PHP auch nicht langsam. Ruby zB hat langsamere Ausführungsgeschwindigkeit als PHP - das ist aber kein Problem weil die Performance mit der Skalierbarkeit des Frameworks steht und fällt.
-
Shade Of Mine schrieb:
Scheppertreiber schrieb:
Sorgen um die Laufzeit des Script muß man sich erst bei heftigen Datenmengen
oder richtig großen Portalen machen ...Nein. Was wichtig ist ist die Skalierbarkeit. Alles andere ist ziemlich uninteressant.
du hast also so viel geld, dass es dir egal ist, ob du zur beantwortung von 100 anfragen 10 server brauchst? skalieren natürlich super horizontal
Shade Of Mine schrieb:
Was man als CGI nimmt ist eigentlich wurscht, ich nehme halt C.
CGI skaliert absolut beschissen. Man sollte immer als Modul des Webservers laufen.
CGI skaliert überhaupt nicht, sondern die an das interface gekoppelte software...
Shade Of Mine schrieb:
Deshalb ist PHP auch nicht langsam.
doch! und schlimmer wirds wenn teenie "hacker" dann auch noch alles selbst in php nachbauen müssen, weil die mitgelieferten funktionen nicht taugen
-
CGI skaliert absolut beschissen. Man sollte immer als Modul des Webservers laufen.
Deshalb ist PHP auch nicht langsam. Ruby zB hat langsamere Ausführungsgeschwindigkeit als PHP - das ist aber kein Problem weil die Performance mit der Skalierbarkeit des Frameworks steht und fällt.
Nein. Wie immer hängt es davon ab ...
Du bringst da einiges durcheinander:
* CGI ist die Schnittstelle, dort laufen die gesendeten Parameter und
die Antwort des Programms drüber.
* die Ausführung ist im aufgerufenen CGI-Programm, dort ist PHP
nicht "schnell".Sollte ich mal an einen Punkt kommen, wo CGI der Flaschenhals ist, schreibe
ich den Kram zum Apache-Modul um, nicht vorher.Das Wichtigste ist, sattelfest im HTML/CSS zu sein, also semantisch korrektes
HTML und sinnvolles CGI. Das ergibt automatisch kurzes HTML, also auch kurze
Verarbeitungs- und Transferzeiten (das Stylesheet etc werden ja nur einmal
übertragen und laufen dann aus dem Chache).Ergo Hirn statt dubioser Frameworks und blabla-Projekten.
-
_-- schrieb:
du hast also so viel geld, dass es dir egal ist, ob du zur beantwortung von 100 anfragen 10 server brauchst? skalieren natürlich super horizontal
Symfonie skaliert zB ein paar Ecken besser als Rails.
PHP ist durch das Sandbox Prinzip prinzipiell ideal für Skalierung geeignet.Niemand redet in diesem Bereich von Sprachen: man redet nur von Frameworks. Denn wie schnell eine Funktion ausgeführt wird ist irrelevant wenn es darum geht viele Anfragen du parallel bearbeiten kannst. Natürlich ist es praktisch wenn eine Funktion schneller ausgeführt wird - aber die essentielle Frage ist: wieviel Arbeit macht das Framework denn? Denn wenn du 100% langsamer ausführst, aber nur 30% der Arbeit machst - bist du immer noch schneller.
Deshalb: Niemand interessiert sich in diesem Bereich für Sprachen. Man redet nur von Frameworks.
CGI skaliert überhaupt nicht, sondern die an das interface gekoppelte software...
Die Software die hinter dem CGI steckt ist uninteressant wenn du CGI verwendest (naja, nicht ganz, aber du kannst so oder so keine große Menge an Anfragen beantworten).
doch! und schlimmer wirds wenn teenie "hacker" dann auch noch alles selbst in php nachbauen müssen, weil die mitgelieferten funktionen nicht taugen
Irrelevant. Unfähige Leute gibt es überall.
Merkt man zB hier. Die Sprache ist nämlich komplett irrelevant. Was zählt ist das Framework. Denn dort liegt die Aufgabe der Skalierung.