Dennis Wronka
Soulcollector
Das sag mal einem der im Karate-Unterricht staendig auf die Fresse kriegt.Sven Mintel hat gesagt.:
PHP? Bitte nicht!
- Themenstarter Christian Fein
- Beginndatum
Sven Mintel
Mitglied
Kein Wunder....wenn du dich nur von Triops und Erdbeerem ernährst, was soll da schon bei rauskommen 
Dennis Wronka
Soulcollector
Ich kann Dir ja mal so ein Vieh schicken, natuerlich ohne Gebrauchsanleitung. Dann kannst Du mal gucken wie Du den gekocht kriegst.
Aber wir kommen vom Thema ab, daher: PHP verleitet zu nicht interoperablem Scripting.
Aber wir kommen vom Thema ab, daher: PHP verleitet zu nicht interoperablem Scripting.
SilentWarrior
Erfahrenes Mitglied
Cool! Danke für den Link, ich hatte schon befürchtet, es stünde wieder ein stundenlanges Herumgesuche im Netz an.Matthias Reitinger hat gesagt.:
Gumbo
Erfahrenes Mitglied
Ich weiß, dass nur Ruby die Programmiersprache ist und Ruby on Rails ein Web-Framework ist. Doch da ich es sowieso darauf hinauslaufen lassen wollte, hab ich direkt Ruby on Rails installiert. Zumal Ruby ja dabei ist, kann ich ja jetzt auch vorerst nur mit Ruby allein arbeiten.Christian Fein hat gesagt.:
Gibt es eigentlich irgendwelche Ruby-Coding-Standards?
Dennis Wronka
Soulcollector
Ruby selbst hab ich mal installiert weil irgendwas das zum kompilieren brauchte (ich glaub eines der KDE-Pakete). Das war bisher aber mein Kontakt zu Ruby.
Wie gesagt, ich beschaeftige mich nach Bedarf mit Programmiersprachen, und zur Zeit hab ich wenig Bedarf an Ruby. Selbst fuer PHP hab ich ja daheim zur Zeit kaum Zeit. Das meiste was bei mir privat an "Programmiererei" abgeht ist Bash-Scripting.
Auf der Arbeit hab ich noch genug mit meinem PHP-Projekt zu tun und dann muss ich hier ja auch noch dieses schimmelige ASP (ohne .NET!) lernen.
Wie gesagt, ich beschaeftige mich nach Bedarf mit Programmiersprachen, und zur Zeit hab ich wenig Bedarf an Ruby. Selbst fuer PHP hab ich ja daheim zur Zeit kaum Zeit. Das meiste was bei mir privat an "Programmiererei" abgeht ist Bash-Scripting.
Auf der Arbeit hab ich noch genug mit meinem PHP-Projekt zu tun und dann muss ich hier ja auch noch dieses schimmelige ASP (ohne .NET!) lernen.
Matthias Reitinger
ɐɯıǝɹ
Hallo,
das wirklich coole an diesem One-Click-Installer ist, dass RubyGems gleich mitgeliefert wird. Was apt für Debian(oide) ist, ist gem nämlich für Ruby: ein Paketsystem, mit dem man bequem Rubyprojekte (sogeannte „Gems“) von einem zentralen Server (die schon erwähnte Rubyforge) beziehen und automatisch installieren lassen kann – inklusiven Auflösung von Abhängigkeiten, versteht sich.
Rails richtet man bspw. ein, indem man gem install -r rails in die Konsole hämmert. Und schon werden die jeweils aktuellsten Pakete (ActionMailer, ActionPack, ActiveRecord, ActiveSupport und Rails selber) in die lokale Rubyinstallation eingepflegt.
Und das schöne daran: wenn man selber an einem Projekt werkelt und dieses anderen zur Verfügung stellen will, kann man relativ simpel ein eigenes Gem erstellen und darf (was sag ich: soll sogar) das dann in der http://rubyforge.org veröffentlichen. Dadurch haben sich inzwischen schon viele Rubyprojekte zentrale an dieser Stelle gesammelt. Kein stundenlanges googeln mehr, wenn man mal eine bestimmte Klasse oder eine bestimmte Extension (ja, auch in C geschriebene Erweiterungen gibt es als Gems, wahlweise als Binärdatei oder zum selberbacken) sucht, und kein nervenraubendes Aufsetzen von PEAR o.ä.
Meiner Meinung nach ein weiterer Vorteil davon: dadurch, dass diese Gems meist kleine, sehr flexibel einsetzbare Module darstellen und RubyGems von offizieller Seite gefördert und unterstützt wird (ab Ruby 1.9 bzw. 2.0 soll es auch in der Standarddistribution enthalten sein, wenn ich mich nicht irre), verringert sich die Gefahr von Codeduplikation auf die gesamte Community gesehen. Jeder schlaue Rubyist (und das ist er schon von Haus aus, weil er ja auf Ruby setzt) schaut nämlich erst mal bei Rubyforge vorbei und verwendet dann bei Bedarf ein Gem, bevor er das Rad neu erfindet. Dadurch ergibt sich auch ein gewisser Wiedererkennungseffekt, wenn man ein Gem schon mal eingesetzt hat und dieses dann bei einem anderen Projekt auch verwendet wird. Bei vielen PHP-Lösungen (um mal die Kurve zu kriegen) ist es ja leider so, dass da jeder sein eigenes Süppchen kocht (bei Datenbankanbindung, Sessionhandling, Benutzerverwaltung etc.). Natürlich gibt es dort auch einige „Standards“, die recht verbreitet sind (AdoDB und Smarty, um nur mal zwei zu nennen), aber meiner Ansicht nach nicht in dem Grade, wie das mit Ruby praktiziert wird.
So, nach dieser kleinen Abhandlung bin ich dann wieder mal Pickaxe lesen.
Viel Spaß und Erfolg an alle, die sich jetzt mit Ruby beschäftigen!
Grüße,
Matthias
PS: Wer mal ein bisschen in Rails reinschnuppern möchte, dem sei der Artikel Rolling with Ruby on Rails von Curt Hibbs an's Herz gelegt. Dazu gibt es auch eine Fortsetzung.
PPS: An dessen Codeformatierung (ich hoffe mal, dass du darauf hinaus wolltest) halten sich nämlich die meisten Rubyprogrammierer.
das wirklich coole an diesem One-Click-Installer ist, dass RubyGems gleich mitgeliefert wird. Was apt für Debian(oide) ist, ist gem nämlich für Ruby: ein Paketsystem, mit dem man bequem Rubyprojekte (sogeannte „Gems“) von einem zentralen Server (die schon erwähnte Rubyforge) beziehen und automatisch installieren lassen kann – inklusiven Auflösung von Abhängigkeiten, versteht sich.
Rails richtet man bspw. ein, indem man gem install -r rails in die Konsole hämmert. Und schon werden die jeweils aktuellsten Pakete (ActionMailer, ActionPack, ActiveRecord, ActiveSupport und Rails selber) in die lokale Rubyinstallation eingepflegt.
Und das schöne daran: wenn man selber an einem Projekt werkelt und dieses anderen zur Verfügung stellen will, kann man relativ simpel ein eigenes Gem erstellen und darf (was sag ich: soll sogar
) das dann in der http://rubyforge.org veröffentlichen. Dadurch haben sich inzwischen schon viele Rubyprojekte zentrale an dieser Stelle gesammelt. Kein stundenlanges googeln mehr, wenn man mal eine bestimmte Klasse oder eine bestimmte Extension (ja, auch in C geschriebene Erweiterungen gibt es als Gems, wahlweise als Binärdatei oder zum selberbacken) sucht, und kein nervenraubendes Aufsetzen von PEAR o.ä. Meiner Meinung nach ein weiterer Vorteil davon: dadurch, dass diese Gems meist kleine, sehr flexibel einsetzbare Module darstellen und RubyGems von offizieller Seite gefördert und unterstützt wird (ab Ruby 1.9 bzw. 2.0 soll es auch in der Standarddistribution enthalten sein, wenn ich mich nicht irre), verringert sich die Gefahr von Codeduplikation auf die gesamte Community gesehen. Jeder schlaue Rubyist (und das ist er schon von Haus aus, weil er ja auf Ruby setzt
) schaut nämlich erst mal bei Rubyforge vorbei und verwendet dann bei Bedarf ein Gem, bevor er das Rad neu erfindet. Dadurch ergibt sich auch ein gewisser Wiedererkennungseffekt, wenn man ein Gem schon mal eingesetzt hat und dieses dann bei einem anderen Projekt auch verwendet wird. Bei vielen PHP-Lösungen (um mal die Kurve zu kriegen) ist es ja leider so, dass da jeder sein eigenes Süppchen kocht (bei Datenbankanbindung, Sessionhandling, Benutzerverwaltung etc.). Natürlich gibt es dort auch einige „Standards“, die recht verbreitet sind (AdoDB und Smarty, um nur mal zwei zu nennen), aber meiner Ansicht nach nicht in dem Grade, wie das mit Ruby praktiziert wird.So, nach dieser kleinen Abhandlung bin ich dann wieder mal Pickaxe lesen.
Viel Spaß und Erfolg an alle, die sich jetzt mit Ruby beschäftigen!
Grüße,
Matthias
PS: Wer mal ein bisschen in Rails reinschnuppern möchte, dem sei der Artikel Rolling with Ruby on Rails von Curt Hibbs an's Herz gelegt. Dazu gibt es auch eine Fortsetzung.
PPS:
Bei Ruby wird schon viel durch die Syntax vorgegeben. Aber ansonsten hat sich das Einrücken mit zwei Leerzeichen pro Ebene durchgesetzt. Da du Rails ja schon installiert hast, wusel dich doch einfach mal durch dessen Quellcode durchGumbo hat gesagt.:
An dessen Codeformatierung (ich hoffe mal, dass du darauf hinaus wolltest) halten sich nämlich die meisten Rubyprogrammierer.
Norbert Eder
Erfahrenes Mitglied
Da das Thema "Programmierung" als Hobby aufkam, muss ich ein paar Worte loswerden:
Genau darin liegt das Problem. Viele glauben, sich schnell so nebenbei mal die 1000. Gallery zu bauen, oder eine super-tolle-dynamische Homepage. Wie passiert dies? Es wird eine PHP Version heruntergeladen und mit dieser wird dann jahrelang gearbeitet. Keiner interessiert sich für Updates, für Dokumente bezüglich Sicherheit, etc. denn das würde ja sehr viel Zeit kosten und die hat man ja nicht. Weil es eben ein Hobby ist. Und das ist falsch. Softwareentwicklung ist jedoch ein kompleter Berufszweig, der eben mal nicht so locker nebenbei erlernt und ausgeübt werden kann. Es ist aufwändig, es ist viel zu lernen und es darf kein Stehenbleiben geben. Ich kann auch nicht eben mal so in meiner Freizeit ein komplettes Haus alleine hinstellen, weil ich der Meinung bin, ich bekomm eine kleine Mauer gerade hin, also wird ein Haus auch funktionieren. Dem ist nicht so.
Und zu dieser Weiterbildung gehört es eben auch für einen Programmierer/Entwickler/Architect dazu, dass er sich mit neuen, alternativen Technologien beschäftigt, als auch mit neuen Versionen der verwendeten Grundlage, ebenso wie Randfelder á la Security.
Was ich damit sagen möchte: Wer sich damit beschäftigt, soll das ausreichend tun und für Neues offen sein. Wer nicht, soll das besser anderen überlassen, die beispielsweise damit ihre Brötchen verdienen.
Genau darin liegt das Problem. Viele glauben, sich schnell so nebenbei mal die 1000. Gallery zu bauen, oder eine super-tolle-dynamische Homepage. Wie passiert dies? Es wird eine PHP Version heruntergeladen und mit dieser wird dann jahrelang gearbeitet. Keiner interessiert sich für Updates, für Dokumente bezüglich Sicherheit, etc. denn das würde ja sehr viel Zeit kosten und die hat man ja nicht. Weil es eben ein Hobby ist. Und das ist falsch. Softwareentwicklung ist jedoch ein kompleter Berufszweig, der eben mal nicht so locker nebenbei erlernt und ausgeübt werden kann. Es ist aufwändig, es ist viel zu lernen und es darf kein Stehenbleiben geben. Ich kann auch nicht eben mal so in meiner Freizeit ein komplettes Haus alleine hinstellen, weil ich der Meinung bin, ich bekomm eine kleine Mauer gerade hin, also wird ein Haus auch funktionieren. Dem ist nicht so.
Und zu dieser Weiterbildung gehört es eben auch für einen Programmierer/Entwickler/Architect dazu, dass er sich mit neuen, alternativen Technologien beschäftigt, als auch mit neuen Versionen der verwendeten Grundlage, ebenso wie Randfelder á la Security.
Was ich damit sagen möchte: Wer sich damit beschäftigt, soll das ausreichend tun und für Neues offen sein. Wer nicht, soll das besser anderen überlassen, die beispielsweise damit ihre Brötchen verdienen.
ZeroEnna
Erfahrenes Mitglied
Naja, da ich selbst viel mit PHP programmiere, will ich auch mal meinen Senf dazu geben
Klar ist PHP nicht das Mass aller Dinge. Wie schon von vielen erwähnt, kopieren die meisten ihre PHP-Scripte aus Tutorials oder ähnlichem, ohne sich gross Gedanken darüber zu machen ob das Script auch wirklich sicher und effizient ist.
Die meisten Tutorials dienen nur als Anregung und sollen Möglichkeiten zur Lösung bestimmter Problematiken aufzeigen. Um die Sicherheit muss man sich immer noch selbst kümmern.
Weiterhin wurde hier die Inkonsistenz von PHP angesprochen. Dies ist eines der grössten Mankos. Ursache hierfür ist letztendlich, dass die Entwickler von PHP immer viel zu grossen Wert auf die abwärts Kompatibilität gelegt haben und so veraltete Methoden und Funktionen immer in der Sprache enthalten geblieben sind. Eine weitere Ursache für die Inkonsistenz ist sicher auch, dass sehr viele Leute an der Entwicklung beteiligt sind, ohne dass es wirklich klar definierte Regeln gibt, wie die Funktionen benannt werden müssen. Es gibt zwar ein paar Dokumente die das versucht haben zu lösen, aber kaum jemand hält sich daran. Hier müsste man viel härter durchgreifen.
Viele behaupten auch, dass man mit PHP nicht objektorientiert programmieren kann. Dem kann ich nicht ganz zustimmen. In PHP 5 sind viele Aspekte der OOP hinzugekommen. Natürlich kann man dies nicht mit Sprachen wie z.B. JAVA vergleichen, aber es ist zumindest schon mal ein Anfang. Kaum jemand versucht wirklich objektorientiert zu programmieren mit PHP. Aber genau dies währe ein Ansatz um häufige Sicherheitsprobleme zu umgehen. Denn je mehr man Objektorientiert programmiert, umso leichter fällt auch das debugen. Ich zumindest hoffe, dass die Entwickler von PHP in der Version 6 nicht mehr so extrem auf abwärts Kompatibilität achten und dass sie dadurch die Sprache auch ein bisschen "säubern".
Aber wie schon von vielen erwähnt, sollte man auch immer Ausschau nach alternativen halten. Ich beschäftige mich in letzter Zeit vermehrt mit Ruby. Es ist wirklich eine sehr elegante Sprache und sie ist auch sehr leicht zu erlernen. Was mir besonders gefällt, ist die Anlehnung an Smalltalk. Ruby wird in Zukunft sicher eine grosse Rolle spielen (so wie es im asiatischen Raum jetzt schon ist), vor allem weil es immer mehr deutschsprachige Lektüre dazu gibt.
Weiterhin möchte ich euch für die Links zu den Ruby-Seiten danken, da waren ein paar dabei die ich noch nicht kannte.
Da hier (oder zumindest hier im Thread) ziemlich viel Interesse an Ruby gezeigt wird, wäre es doch auch mal an der Zeit hier im Forum mal eine Ruby Sektion ei zu richten. Denn leider ist die deutschsprachige Community von Ruby noch nicht extrem gross und mit der Einführung einer Ruby-Sektion hier im Forum würde tutorials.de sicher auch einen grossen Beitrag zum Vorstoss von Ruby leisten.
So, dass war’s dann erstmal von mir. Sorry, falls ich hier totalen Schwachsinn von mir gegeben habe
mfG
ZeroEnna
Klar ist PHP nicht das Mass aller Dinge. Wie schon von vielen erwähnt, kopieren die meisten ihre PHP-Scripte aus Tutorials oder ähnlichem, ohne sich gross Gedanken darüber zu machen ob das Script auch wirklich sicher und effizient ist.
Die meisten Tutorials dienen nur als Anregung und sollen Möglichkeiten zur Lösung bestimmter Problematiken aufzeigen. Um die Sicherheit muss man sich immer noch selbst kümmern.
Weiterhin wurde hier die Inkonsistenz von PHP angesprochen. Dies ist eines der grössten Mankos. Ursache hierfür ist letztendlich, dass die Entwickler von PHP immer viel zu grossen Wert auf die abwärts Kompatibilität gelegt haben und so veraltete Methoden und Funktionen immer in der Sprache enthalten geblieben sind. Eine weitere Ursache für die Inkonsistenz ist sicher auch, dass sehr viele Leute an der Entwicklung beteiligt sind, ohne dass es wirklich klar definierte Regeln gibt, wie die Funktionen benannt werden müssen. Es gibt zwar ein paar Dokumente die das versucht haben zu lösen, aber kaum jemand hält sich daran. Hier müsste man viel härter durchgreifen.
Viele behaupten auch, dass man mit PHP nicht objektorientiert programmieren kann. Dem kann ich nicht ganz zustimmen. In PHP 5 sind viele Aspekte der OOP hinzugekommen. Natürlich kann man dies nicht mit Sprachen wie z.B. JAVA vergleichen, aber es ist zumindest schon mal ein Anfang. Kaum jemand versucht wirklich objektorientiert zu programmieren mit PHP. Aber genau dies währe ein Ansatz um häufige Sicherheitsprobleme zu umgehen. Denn je mehr man Objektorientiert programmiert, umso leichter fällt auch das debugen. Ich zumindest hoffe, dass die Entwickler von PHP in der Version 6 nicht mehr so extrem auf abwärts Kompatibilität achten und dass sie dadurch die Sprache auch ein bisschen "säubern".
Aber wie schon von vielen erwähnt, sollte man auch immer Ausschau nach alternativen halten. Ich beschäftige mich in letzter Zeit vermehrt mit Ruby. Es ist wirklich eine sehr elegante Sprache und sie ist auch sehr leicht zu erlernen. Was mir besonders gefällt, ist die Anlehnung an Smalltalk. Ruby wird in Zukunft sicher eine grosse Rolle spielen (so wie es im asiatischen Raum jetzt schon ist), vor allem weil es immer mehr deutschsprachige Lektüre dazu gibt.
Weiterhin möchte ich euch für die Links zu den Ruby-Seiten danken, da waren ein paar dabei die ich noch nicht kannte.
Da hier (oder zumindest hier im Thread) ziemlich viel Interesse an Ruby gezeigt wird, wäre es doch auch mal an der Zeit hier im Forum mal eine Ruby Sektion ei zu richten. Denn leider ist die deutschsprachige Community von Ruby noch nicht extrem gross und mit der Einführung einer Ruby-Sektion hier im Forum würde tutorials.de sicher auch einen grossen Beitrag zum Vorstoss von Ruby leisten.
So, dass war’s dann erstmal von mir. Sorry, falls ich hier totalen Schwachsinn von mir gegeben habe
mfG
ZeroEnna
Christian Fein
Erfahrenes Mitglied
ZeroEnna hat gesagt.:
sorry aber das ist Blödsinn. Abwärts Kompatiblität bieten andere Sprachen genauso !ohne! das deswegen eine solche Inkonsistenz auftritt.
Wohl weil in anderen Sprachen diese Fehler nicht so intensiev gemacht wurden im Vergleich zu PHP.
Wenn sowenig Kontrolle erfolgt, ist mein Vertrauen in die Sprache sowieso = 0. OpenSource bedeutet nicht ohne Kontrolle und System. Wenn der Kernel nach der
Methode entwickelt würde das es keinen Interressiert wie etwas programmiert wurde, dann hätten wir nichtmals annähernd den Status in Sicherheit und Stabilität im Linux Kernel. Auch das Debian Projekt, welches nun sehr auf OpenSource achtet hat da
ganz klare Regeln.
Wenn sowas bei der PHP Entwicklung nicht beachtet wird dann taugt da etwas nicht.
Das OOP Konzept von PHP ist Müll. Es ist die Kopie von Java. Es ist deswegen Müll weil PHP als Scriptsprache ganz andere Möglichkeiten hat wie eine Sprache Java.
Zudem erlaubt PHP nur das OOP Programmieren, ist aber selber keine OOP Sprache. Mann erkennt es daran das der Standardumang nur mit Funktionen daher kommt.
Geöffnete Dateien werden in Handles gespeichert und nicht in File Objekten. Der ganze Sprachumfang von PHP ist auf prozeduale Programmierung ausgelegt und hat mit OOP
gar nichts zu tun.
Deshalb kann ich mich an kein PHP Projekt errinnern das ich bisher im SourceCode gesehen habe (und ich habe einige gesehen) das OOP sauber umgesetzt hat.
In Python und Ruby, sind auch Methoden Objecte. Sie brauchen sich nicht an OOP von Java zu orientieren da sie durch ihre Dynamic da noch einen draufsetzen können.
Da Scriptsprachen wie Ruby, Python um einiges langsamer sind als Java/.net/ (dafür um einiges schneller als PHP) müssen sie andere Vorteile bieten. Das tun sie durch die erweiterten OOP / Funktionalen Möglichkeiten wie Pythons map() filter() reduce() generatoren usw.
PHP bietet im Sprachdesign aber gegenüber C#/ Java überhaupt keine Vorteile, sondern nur Nachteile. Gepaart mit einer noch langsameren Ausführungsgeschwindigkeit als andere Scriptsprachen.
Mann bastelt an PHPs OOP Fähigkeit seid Version 3 rum. Und genauso alt ist der Wunsch das auch der Sprachumfang überarbeitet wird. Vielleicht wirds mit Version 9 was .... Bis dahin ists einfach nur "crap!"
Leider bringen Foren die erstmals kaum besucht werden relativ wenig. Da fast leere Foren eine Sprache kaum puschen.
Was viel mehr bringen würde sind einfach Beiträge / Tutorials von jenen die Python bzw Ruby einsetzen.
Im übrigen ist Python bzw Ruby schon jetzt sehr erfolgreich und stark eingesetzt. Auch wenn das auf tutorials.de nicht erkennbar ist
So, dass war’s dann erstmal von mir. Sorry, falls ich hier totalen Schwachsinn von mir gegeben habe
Nö hast du nicht
