interessante frage zum string casting

[closure]

Original geschrieben von wahsaga
Grundsätzlich will ich mich in die Diskussion eigentlich gar nicht einmischen, aber ...

Sehe ich das richtig, dass hier eine Methode upto eines Zahlenobjekts(?) 0 mit dem Parameter 10 aufgerufen wird, um von 0 bis 9 zu laufen ...?

Das siehst du richtig. Dazu musst du aber wissen dass es
eine designentscheidung von ruby war, dass alles ein objekt ist.
Wirklich alles. Sogar Klassen selbst sind objekte. (genau genommen
gibt es bei klassen eine kleine abweichung von der regel, die
hier aber nicht weiter von belang ist)
Das mag etwas esoterisch klingen wenn man diese sichtweise
nicht gewohnt ist eröffnet aber einige möglichkeiten, die nur
in ruby möglich sind, weil es durchweg so designed wurde.

Selbst literale sind objekte.

"ich bin ein string".length
[1,2,3,4].select { |i| i == 3 }
3.times do sth end

Funktioniert alles.

Original geschrieben von wahsaga
Was mich daran wirklich stört ist, dass der "Startwert" ein Objekt darstellt, der Endwert wiederum nur ein Parameter ist - sorry, aber diese Notation ist wirklich hässlich und intransparent in meinen Augen.

Der endwert ist ebenfalls ein objekt. In diesem konkreten fall
eine instanz von Fixnum.

Original geschrieben von wahsaga
Das ist ja in etwa das gleiche, als wenn ich zum Vergleichen von zwei Zahlen keinen schlichten Operator mehr nehmen würde - sondern dazu eine Vergleichsmethode eines Zahlenobjektes nehme, und der die andere Zahl als Parameter übergebe ...

7.isEqualTo(13)

Da bist du näher an der realität als du denkst. Denn genau so
ist es. Die methode heisst eben nur nicht "isEqualTo" sondern "==".

Und

5 == 3

ist nur syntactic sugar für

5.==(3)

Original geschrieben von wahsaga
Das klingt für mich eher nach Objektorientierung um der Objektorientierung willen, auf Teufel komm' raus, und nicht weil sie an der Stelle etwa sinnvoll wäre.

Wie gesagt, eine designentscheidung.
Das halte ich an dieser stelle nicht für falsch. Weil es wie beschrieben erhebliche vorteile bring.

Smalltalk und python etwa gingen und gehen den selben weg.

greets

[closure]

Original geschrieben von Slava
ich sage doch das es Geschmacksache ist, und ich finde Ruby-syntax nicht nur unübersichtlich, sondern auch richtig hässlich.
Villeicht wird ein VB-Programmierer sich auf so ein Syntax freuen, aber ich würde mal fui sagen.

Ok, über geschmack lässt sich nicht streiten. Es muss ja auch
andere meinungen geben.

Original geschrieben von Slava
Vielleich liegt es daran, dass ich eigentlich nur c, c++, java, c#, javascript und einwenig Actionscript programmiert habe.
shellscripting habe ich auch ein wenig gemacht, aber finde der Syntax nur für ganz kleine Programmstücke akzeptabel

Hmm all die sprachen , mit ausnahme von actionscript, habe ich
ebenfalls benutzt. Naja der geschmack eben.



greets

[wahsaga]

Original geschrieben von closure
Selbst literale sind objekte.

Also starke Ähnlichkeit zum OO-Konzept von Javascript - da ist die Syntax "abc".length und ähnliches ja auch definiert.

Hab mich mit RubyOnRails bisher nur mal kurz beschäftigt - ein kleines Beispieltutorial durchgearbeitet. Ergebnisse erzielt man damit wirklich sehr schnell (mit anderen Frameworks in anderen Sprachen aber sicher auch) - aber ich mag generell Frameworks nicht so, weil ich da das Gefühl habe zu wenig Kontrolle über den Code, der letztendlich rauskommt zu haben. Außerdem lerne ich dabei ja weniger mit einer Sprache umzugehen, als viel mehr ein Framework zu bedienen - eher langweilig.

Ruby als Sprache ist sicherlich eine interessante Angelegenheit - muss mal schauen, wann ich mal Zeit (und Lust) finde, mich damit eingehender zu beschäftigen.

[closure]

Original geschrieben von wahsaga
Also starke Ähnlichkeit zum OO-Konzept von Javascript - da ist die Syntax "abc".length und ähnliches ja auch definiert.

Ja der vergleich ist gar nicht so schlecht. Javascript benutzt ja auch
das metaobjectprotokoll. Die prototype library beispielsweise
sieht rubycode gar nicht so unähnlich.

Original geschrieben von wahsaga
[...] aber ich mag generell Frameworks nicht so, weil ich da das Gefühl habe zu wenig Kontrolle über den Code, der letztendlich rauskommt zu haben. Außerdem lerne ich dabei ja weniger mit einer Sprache umzugehen, als viel mehr ein Framework zu bedienen - eher langweilig.

Immer und immer wieder den selben code schreiben zu müssen um ein
neues projekt im "mvc-mode" zu bootstrappen ist mindestens
genauso langweilig. Frameworks sollen dir arbeit abnehmen damit
du dich auf die eigentliche aufgabe, die businesslogik im railsfall,
konzentrieren kannst.
Ganz klar gibt es da auch andere frameworks die wirklich gut sind.
Aber rails kann dank ruby und dessen support für domains specific
languages und des convention-over-configuration-mantras ein paar
dinge, die es wie magie erscheinen lassen. Aber ganz klar, ohne
ruby zu kennen kann man auch mit rails nichts großes reißen.

Ein weiterer großer vorteil ist es dass man mit rails wirklich nur
ruby können muss. Es gibt generatoren die dir das schreiben
von html abnehmen (natürlich braucht man ein grundlegendes
verständnis dieser auszeichnungssprache). Auch javascript wird
in entsprechende rubyobjekte gekapselt und ebenso soll
support für css kommen.
Man kann sich hierzu mal: markaby ansehen. Oder mal nach "rjs templates" googlen.

Original geschrieben von wahsaga
Ruby als Sprache ist sicherlich eine interessante Angelegenheit - muss mal schauen, wann ich mal Zeit (und Lust) finde, mich damit eingehender zu beschäftigen.

Es lohnt sich definitiv. Ich bin über rails zu ruby gekommen. Und
mache nun fast alles mit ruby, und freu mich wie entspannt man
damit agile prinzipien umsetzen und damit produktiver sein kann.
Ruby forciert dabei nichts. es gibt allenfalls kleine seitenhiebe aber
lässt einem die entscheidung offen einen ganz eigenen weg zu gehen.

greets

[ghostgambler]

Original geschrieben von closure
Es ist wie bereits gesagt geschmackssache. Ich bevorzuge eine
intuitive syntax.

Ich bin ehrlich gewillt mich auf neue Dinge einzulassen, hab mir also gerade ein paar Dutzen Sachen in Sachen ruby zu genüge geführt...
Benchmark, Ruby und PHP gleichen sich in etwa aus. PHP braucht in vielen Fällen weniger (teilweise 50%) Ram, Ruby ist etwas fixer in der Ausführung -> Kein Grund zum Wechsel
Ein 5 Minuten interaktives Tutorial zu Ruby (ohne Rails). Die Syntax ist einfach nur zum Schießen, mehr nicht. Ich habe mir die "Tipps" für "Umsteiger" sowohl von PHP als auch von Java und Python angeschaut. Von PHP, ne Menge Änderungen, bei Java stand bei, dass die meisten Leute sehr zu Ruby tendieren, wegen dem hohen Abstraktionslevel ... finde ich definitiv nicht. Abstraktion ist in Ruby gegeben, aber vollkommen inkonsistent implementiert, da ist Java um ein wesentliches klarer strukturiert und Java ist PHP wesentlich näher, als Ruby...
Das Python's Syntax Käse ist, wusste ich auch vorher schon, demzufolge habe ich die weiteren Änderungen von Python zu Ruby, nur mit einem Schmunzeln abtun können ... es wurde noch unstrukturierter.

Ich sehe nichts was daran toll ist. Die spl ist ein unschöner versuch zusammen
mit dem vermurksten iteratorkonzept von php etwas stl-ähnliches zu
erschaffen. Mit mäßigem erfolg. Iteratoren in php sind keine container-unabhänige
schnittstelle.

Bla! Mehr fällt mir zu dem kompletten Absatz nicht ein.
Glaubst du im Ernst ich verlinke einen 2 Seiten-Artikel pro PHP, damit du dir den einen Absatz über SPL durchliest und darauf hin argumentierst?

Du darfst rails nicht mit ruby gleichsetzen. Ruby ist eine moderne
programmiersprache. Rails ist ein webframework dass mittels dieser
sprache implementiert wurde.

Ich muss dich enttäuschen, nur weil die pro-Ruby-Leute sagen, Ruby sei modern, heißt es nicht, dass Ruby wirklich modern ist; das ist eine ganz subjektive Sichtweise.
Für mich ist Ruby der verzweifelte Versuch einen Vorsprung in Sachen Programmierung zu machen, der aber in die vollkommen falsche Richtung geht.
Wir sind in Sachen imperative Programmierparadigmen, mit OOP vorläufig an der Grenze der guten Struktur angelangt; was Ruby jetzt versucht ist durch den Wechsel der Syntax, eine qualitativ bessere und übersichtlichere Art der Programmierung zu schaffen.
Das Einzige was damit geschaffen wird, ist eine neue Form unnützer Syntax.

Die vollständige Objektorientierung ist auch in Java schon vorhanden (abgesehen von der Typisierung von Literalen, aber das ist ja sowieso Banane...), und wurde da mit der normalen Syntax genauso gut vollzogen; wozu also auf den Hype der vollkommen unverständlichen Ruby-Syntax aufspringen?

PHP ist und bleibt für mich erste Wahl für Webprogrammierung.
Ob der oben genannte Benchmark überhaupt die Binary-Caches von PHP beachtet/genutzt hat, weiß ich nicht; wenn nicht, muss man die Statistik eh mit Vorsicht genießen, denn die Bin-Caches können eine Menge ausmachen.
Stößt PHP an seine Grenzen, weiche ich lieber auf C/C++ oder Java aus, das ist eine wesentlich bessere Entscheidung als Ruby, denn Ruby wird trotz fortschrittlicher Syntax nur interpretiert (ob Java auch "nur" "interpretiert" wird, darüber kann man wahrscheinlich soviel Text drüber diskutieren, wie php vs. Ruby, aber egal...).



Was lerne ich als PHPler aus dieser Diskussion?
Der einzige gravierende Nachteil von PHP ist die dynamische Typisierung.
Problem: Das ist auch einer der Vorteile von PHP
Lösung: Der Programmierer kann SELBST wählen, ob er die dynamische Typisierung nutzen will oder nicht (entweder er verwendet durchgängig == oder ===)
Folge: Was war jetzt nochmal der Vorteil von Ruby?

Und wenn jemand wirklich der Meinung ist, Rails sei so toll und man müsse unbedingt ein Framework haben:
Zend Framework
CakePHP Framework

Die Frage bleibt: Wo ist der Vorteil von Ruby?

[closure]

Normalerweise argumentiere ich nicht auf diese weise.
Ich hab mir gerade mal dein profil angeschaut. Du bist ein
18 jähriger schüler. Soweit erstmal nichts verwerfliches.
Und es sagt zunächst mal auch nichts über deine qualifikation
aus. Aber dieser fakt und deine posts, insbesondere der letzte, bringen mich
dazu die diskussion mit dir nur widerwillig fortzuführen.
Das ist nicht so abwertent gemeint wie es vll. klingt. Es ist
einfach so dass wir aufgrund fehlender erfahrungswerte und fehlendem
wissen, die diskussion auf diesem level nicht fortführen können.

Original geschrieben von ghostgambler
Benchmark, Ruby und PHP gleichen sich in etwa aus. PHP braucht in vielen Fällen weniger (teilweise 50%) Ram, Ruby ist etwas fixer in der Ausführung -> Kein Grund zum Wechsel

edit: typo ausgeglichen. Gemeint war nicht laufzeit sondern speicherverbrauch
Wieviele anwendungen in dem bereich um den es geht kennst
du bei denen der speicher der kritische faktor ist ? Du weisst,
dass hardware immer billiger wird ?

Original geschrieben von ghostgambler
Ein 5 Minuten interaktives Tutorial zu Ruby (ohne Rails). Die Syntax ist einfach nur zum Schießen, mehr nicht.

Es ehrt dich dass du es dir zumindest mal angeschaut hast.
Schön wäre hier auch noch eine begründung gewesen.

bei Java stand bei, dass die meisten Leute sehr zu Ruby tendieren, wegen dem hohen Abstraktionslevel ... finde ich definitiv nicht. Abstraktion ist in Ruby gegeben, aber vollkommen inkonsistent implementiert,

Auch dafür hätte ich gern mal einen beleg. Das OO-Konzept von
java ist ein völlig anderes.
Ich möchte wirklich gerne wissen welchen inkonsistenzen du
ausgemacht hast. Vll hab ich ja was übersehen.

Das Python's Syntax Käse ist, wusste ich auch vorher schon, demzufolge habe ich die weiteren Änderungen von Python zu Ruby, nur mit einem Schmunzeln abtun können ... es wurde noch unstrukturierter.

Schön dass es dich wenigstens amüsiert hat.
Was genau meinst du mit "Käse" ?

Bla! Mehr fällt mir zu dem kompletten Absatz nicht ein.
Glaubst du im Ernst ich verlinke einen 2 Seiten-Artikel pro PHP, damit du dir den einen Absatz über SPL durchliest und darauf hin argumentierst?

Ein artikel pro php und ein artikel pro rails. Hast du den zweiten
artikel gelesen ?
Beim ersten artikel war nichts was einen kommentar wert gewesen
wäre ausser der spl.

Ich muss dich enttäuschen, nur weil die pro-Ruby-Leute sagen, Ruby sei modern, heißt es nicht, dass Ruby wirklich modern ist; das ist eine ganz subjektive Sichtweise.
Für mich ist Ruby der verzweifelte Versuch einen Vorsprung in Sachen Programmierung zu machen, der aber in die vollkommen falsche Richtung geht.

Ich habe nie behauptet dass es um neue paradigmen geht.
Ruby hat von anderen sprachen gelernt und unterstützt moderne
methoden um die softwareentwicklung zu vereinfachen und den
spaß in die arbeit zurück zu bringen.

Wir sind in Sachen imperative Programmierparadigmen, mit OOP vorläufig an der Grenze der guten Struktur angelangt; was Ruby jetzt versucht ist durch den Wechsel der Syntax, eine qualitativ bessere und übersichtlichere Art der Programmierung zu schaffen.
Das Einzige was damit geschaffen wird, ist eine neue Form unnützer Syntax.

Den ersten satz habe ich nicht verstanden.
Das ich beim zweiten absolut nicht deiner meinung bin sollte klar
sein.

Die vollständige Objektorientierung ist auch in Java schon vorhanden (abgesehen von der Typisierung von Literalen, aber das ist ja sowieso Banane...), und wurde da mit der normalen Syntax genauso gut vollzogen;

Das stimmt nicht. Es gibt auch in java z.B. builtin integers die
keine objekte sind. Der typ int.

PHP ist und bleibt für mich erste Wahl für Webprogrammierung.
Ob der oben genannte Benchmark überhaupt die Binary-Caches von PHP beachtet/genutzt hat, weiß ich nicht; wenn nicht, muss man die Statistik eh mit Vorsicht genießen, denn die Bin-Caches können eine Menge ausmachen.

Traue keiner statitistik, die du nicht selbst gefälscht hast.

Stößt PHP an seine Grenzen, weiche ich lieber auf C/C++ oder Java aus, das ist eine wesentlich bessere Entscheidung als Ruby, denn Ruby wird trotz fortschrittlicher Syntax nur interpretiert (ob Java auch "nur" "interpretiert" wird, darüber kann man wahrscheinlich soviel Text drüber diskutieren, wie php vs. Ruby, aber egal...).

Nun wie bereits geschrieben habe ich lange zeit in c++-entwickelt.
Aber bevor ich zu c++ für webanwendungen wechsle muss es schon
ein paar triftige gründe geben.
Ruby wird im moment interpretiert ab ruby2.0 wird sich
das ändern.

Was lerne ich als PHPler aus dieser Diskussion?
Der einzige gravierende Nachteil von PHP ist die dynamische Typisierung.
Problem: Das ist auch einer der Vorteile von PHP
Lösung: Der Programmierer kann SELBST wählen, ob er die dynamische Typisierung nutzen will oder nicht (entweder er verwendet durchgängig == oder ===)

Der aufmerksame leser lernt, dass php wesentlich mehr nachteile
hat.

Btw. sind ruby,python,perl,scheme,lisp ebenfalls dynamisch
typisiert. Komisch bei den sprachen gibt es solches verhalten nicht.
Was sagt uns das ?

Der php-parser ist nicht gerade ein glanzstück in der kunst
des interpreterbaus. Ich erinner mich an einen bug, als ein
kommentar am ende eines scripts ein fatal error auslöste.

Folge: Was war jetzt nochmal der Vorteil von Ruby?

offene klassen.
folgt dem prinzip der geringsten überraschung
metaobjectprotocoll.
kontrollierte mehrfachvererbung durch mixins.
code-blöcke als closures
continuations
support für gängige idiome und umsetzung in den coreklassen
namespaces durch modules
duck-typing
intuitive und conzise syntax
umfangreiche bibliotheken
usw.

Und wenn jemand wirklich der Meinung ist, Rails sei so toll und man müsse unbedingt ein Framework haben:
Zend Framework
CakePHP Framework

Dem ist noch znf hinzuzufügen.
Ist ein nettes framework aber nicht annähernd so umfangreich wie
rails.

greets

[ghostgambler]

Original geschrieben von closure
Normalerweise argumentiere ich nicht auf diese weise.
Ich hab mir gerade mal dein profil angeschaut. Du bist ein
18 jähriger schüler. Soweit erstmal nichts verwerfliches.
Und es sagt zunächst mal auch nichts über deine qualifikation
aus. Aber dieser fakt und deine posts, insbesondere der letzte, bringen mich
dazu die diskussion mit dir nur widerwillig fortzuführen.
Das ist nicht so abwertent gemeint wie es vll. klingt. Es ist
einfach so dass wir aufgrund fehlender erfahrungswerte und fehlendem
wissen, die diskussion auf diesem level nicht fortführen können.

Und du denkst, nur weil du dir dein Brot mit Webprogrammierung verdienst, hast du mehr Erfahrung und mehr Wissen?
Ich fürchte ich muss dich enttäuschen, Enthusiasmus gleicht viel aus; ganz abgesehen davon, dass es ein Unding ist, mich aufgrund meines Alters oder Status als unqualifiziert für eine Diskussion abzustempeln. Das ist dreist, frech und unfair und sollte von Erwachsenen nicht praktiziert werden, aber das hast du deinem ersten Satz zufolge ja selbst schon gemerkt... (fragt sich bloß warum du dann trotzdem damit angefangen hast)

Wieviele anwendungen in dem bereich um den es geht kennst
du bei denen der speicher der kritische faktor ist ? Du weisst,
dass hardware immer billiger wird ?

Ich weiß, dass es trotz immer billig werdender Hardware doch bei jedem Projekt immer wieder nicht nur auf gut strukturierten Code, sondern auch auf akzeptable Performance ankommt.
Wenn ein Projekt, mit einfachem Tuning, statt mit 20 Servern, mit 2en auskommt, ist das trotz allem ein Kostenfaktor, den niemand ignorieren sollte und niemand ignorieren wird.

Es ehrt dich dass du es dir zumindest mal angeschaut hast.
Schön wäre hier auch noch eine begründung gewesen.

Die folgte ja unten: Ich erachte es als sinnlos, eine neue Form von Syntax zu designen, wenn es doch im Endeffekt auf das gleiche Ergebnis hinaus zielt.

Auch dafür hätte ich gern mal einen beleg. Das OO-Konzept von java ist ein völlig anderes.

Objektorientierte Programmierung ist Objektorientierte Programmierung; egal in welcher Syntax
Falls du Unterschiede siehst, wirst du mir diese aufzeigen müssen.

Ich möchte wirklich gerne wissen welchen inkonsistenzen du ausgemacht hast. Vll hab ich ja was übersehen.

Offene Klassen. Tut mir leid, aber ich erachte sie als hochgradig verwirrend, unnütz und verschleiernd, auch wenn sie zugegebenermaßen reizvoll sind.

Was genau meinst du mit "Käse" ?

das, was ich von der Syntax halte.

Ein artikel pro php und ein artikel pro rails. Hast du den zweiten artikel gelesen ?

Welchen zweiten Artikel?

Ich habe nie behauptet dass es um neue paradigmen geht. Ruby hat von anderen sprachen gelernt und unterstützt moderne methoden um die softwareentwicklung zu vereinfachen und den spaß in die arbeit zurück zu bringen.

Welche "modernen" Methoden meinst du unterstützt Ruby, die den "Spaß" an der Arbeit zurück bringen? Oder meinst du damit vielmehr Rails, was dann wiederum vollkommen off-topic wäre, weil es der Vergleich zwischen einer Programmiersprache und einem Framework ist
(btw. Ich habe meinen Spaß mit PHP und kriege nicht mal Geld dafür...)

Den ersten satz habe ich nicht verstanden.

Es heißt ganz einfach, dass eine Verbesserung der bestehenden Programmiertechniken nicht dadurch möglich ist, dass man die Syntax ändert.

Das ich beim zweiten absolut nicht deiner meinung bin sollte klar sein.

Habe ich auch nicht erwartet...

Das stimmt nicht. Es gibt auch in java z.B. builtin integers die keine objekte sind. Der typ int.

Auf die man aber ohne Probleme verzichten kann, womit Java rein objektorientiert endet

Traue keiner statitistik, die du nicht selbst gefälscht hast.

Bezahl mir 20€ die Stunde und ich teste gerne Ruby gegen PHP aus. Solange suche ich mir Statistiken im Internet ^^,

Btw. sind ruby,python,perl,scheme,lisp ebenfalls dynamisch
typisiert. Komisch bei den sprachen gibt es solches verhalten nicht.
Was sagt uns das ?

Dass du dich an einen einzigen Nachteil von PHP klammerst?
Ernsthaft, das Verhalten von PHP ist inkorrekt, lässt sich aber durch ein dreifaches Gleichheitszeichen umgehen, womit dieser Nachteil wiederum in den Schatten gestellt wird. (Was natürlich trotzdem nichts daran ändert, dass das Verhalten so sch* ist)

offene klassen.

siehe oben

folgt dem prinzip der geringsten überraschung

Sehr subjektiver Vorteil, meinst du nicht?

metaobjectprotocoll.

Auch eines der "Features", die ich in die Kategorie der offenen Klassen packe

kontrollierte mehrfachvererbung durch mixins.

Spielerei; auch wenn die Mehrfachvererbung ein Vorteil gegenüber PHP ist, den ich teilweise auch misse, aber dafür nicht auf die Syntax von Ruby umsteigen würde...

code-blöcke als closures

nice-to-have, aber kein must-have, abgesehen davon, dass es in Funktionen gegeben ist

continuations

Wozu benötigt?

support für gängige idiome und umsetzung in den coreklassen

Solange du keine Beispiele bringst, ist das Argument nutzlos

namespaces durch modules

Namespaces machen (gerade für Anfänger) vieles komplizierter und sie lassen sich durch OOP leicht emulieren

duck-typing

Ohne Worte...

intuitive und conzise syntax

subjektiv

umfangreiche bibliotheken

Ein Blick in die php Manual verrät mir, dass das es eine Menge first-party-exts gibt. Ganz zu schweigen von dem Müll, denn man per Google findet

[closure]

Original geschrieben von ghostgambler
Und du denkst, nur weil du dir dein Brot mit Webprogrammierung verdienst, hast du mehr Erfahrung und mehr Wissen?

Nein aber weil ich auf einige jahre an erfahrungen im bereich softwareentwicklung
im kommerziellen umfeld zurückblicken kann.
Hinzu kommt stoff den man erst auf der uni lernt.

Ich fürchte ich muss dich enttäuschen, Enthusiasmus gleicht viel aus; ganz abgesehen davon, dass es ein Unding ist, mich aufgrund meines Alters oder Status als unqualifiziert für eine Diskussion abzustempeln. Das ist dreist, frech und unfair und sollte von Erwachsenen nicht praktiziert werden, aber das hast du deinem ersten Satz zufolge ja selbst schon gemerkt... (fragt sich bloß warum du dann trotzdem damit angefangen hast)

Enthusiasmus gleicht keine erfahrung aus.
Ich stemple dich nicht als diskussionsunfähig ab, ich spreche dir lediglich
ein gewisses wissen ab, dass aber für diese diskussion von vorteil wäre.

Ich weiß, dass es trotz immer billig werdender Hardware doch bei jedem Projekt immer wieder nicht nur auf gut strukturierten Code, sondern auch auf akzeptable Performance ankommt.
Wenn ein Projekt, mit einfachem Tuning, statt mit 20 Servern, mit 2en auskommt, ist das trotz allem ein Kostenfaktor, den niemand ignorieren sollte und niemand ignorieren wird.

Ich rede nicht von einfachem tuning. Denn wenn es darum geht, sind die
unterschiede ohnehin belanglos. Hardware ist billiger als entwicklungskosten.

Die folgte ja unten: Ich erachte es als sinnlos, eine neue Form von Syntax zu designen, wenn es doch im Endeffekt auf das gleiche Ergebnis hinaus zielt.

Es geht doch nicht nur um die syntax. Das selbe ergebnis ist es immer.
Alle gängigen programmiersprachen sind turingcomplete. Sie können
alle das selbe leisten. Die frage ist wieviel kraft , zeit, knowhow und geld
man investieren will um das selbe ziel zu ereichen.

Objektorientierte Programmierung ist Objektorientierte Programmierung; egal in welcher Syntax
Falls du Unterschiede siehst, wirst du mir diese aufzeigen müssen.

Das oo-konzept beschreibt einige wesentliche merkmale, die das paradigma
vorteilhaft erscheinen lassen. Bei der konkreten umsetzung gibt es jedoch
unterschiede. Soll heissen bei den sprachlichen mitteln die einem zur
verfügung gestellt werden. Es ist ohne weiteres möglich in C objektorientiert
zu programmieren, Das betrifft beides, sowohl die projektmethodik als auch
die implementierung.
Zunächst kann man sich mal c++ anschauen. C++ als hybridsprache
unterstützt den entwickler mit sprachlichen mitteln um eine bestimmtes
OO-Konzept umsetzen zu können. Aber c++ kennt von haus aus
keine metaobjekte. Es gibt beispielsweise kein class-objekt.
Es gibt neben dem klassenbasierten konzept z.B. auch noch
prototypbasierte oder eben objektbasierte konzepte.
Auch beim message-passing gibt es kleine aber feine unterschiede.
Sicher kann man die verschiedenen methoden emulieren, aber
das design der sprache und die wahl des OO-konzepts lenkt einen
in eine bestimmte bahn.
Btw. sind einige features der OOP in php nicht verfügbar.
Etwa multimethods und multiple inheritance. Echte ctors und dtors
gibt es auch nicht. Polymorphie ist nur sehr eingeschränkt möglich.

Welchen zweiten Artikel?

Der zweite von dir im entsprechenden post gegebene link verweisst darauf.

Welche "modernen" Methoden meinst du unterstützt Ruby, die den "Spaß" an der Arbeit zurück bringen? Oder meinst du damit vielmehr Rails, was dann wiederum vollkommen off-topic wäre, weil es der Vergleich zwischen einer Programmiersprache und einem Framework ist

Nein ich meine ruby nicht rails.
Ruby unterstützt rapid prototyping hervorragend. Die irb als interaktiver
rubyinterpreter erlaubt es inkrementel am system zu entwickeln.
Die codierung selbst ist aufgrund des durchdachten designs mit weniger
überraschungen gespickt. Ruby erlaubt durch seine conzise syntax und
die zur verfügung stehenden mittel eine fast unmittelbare codierung der
algorithmus forderung mit intuitiven formalen elementen. Ruby hat
einen herforragenden support für testgetriebene entwicklung. You know
"red, green, refactor" ?

Aber, und das ist wichtig, ruby wurde mit dem gedanken spaß bei der
arbeit zu haben entworfen. Es soll dem entwickler spaß machen seine
arbeit zu erledigen. Es soll nicht frustriert und dadurch demotiviert werden.
Frustration wird erzeugt durch unnötig komplexe zusammenhänge.
Unnötig aufgeblähte syntax.
Inkonsistenzen in der sprache. Orthogonalität der sprachfeatures.

Schau dir doch mal php an.
strstr()
strtok()
strlen()

aber

str_replace()
str_count()
substr_compar()
parse_str()

Das sind nur funktionsnamen. Es wird noch besser wenn man sich
die parameterreihenfolge verschiedener funktionen anschaut.
Weil es thematisch gut in den thread passt. Schau dir mal
an was in php alles als FALSE gilt.

      das boolean FALSE selbst

      die Integer 0 (Null)

      die Fließkomma-Zahl 0.0 (Null)

      die leere Zeichenkette und die Zeichenkette "0"

      ein Array ohne Elemente

      ein Objekt ohne Mitgliedsvariablen

      der spezielle Typ NULL (einschließlich nicht definierter Variablen)

Da sind 5 überraschungen. Alles ab Fließkomma 0.0.
Was soll das ? Warum ist ein array() ohne element FALSE ?
Warum ist ein objekt ohne member FALSE ?
Warum gilt FALSE == "" == "0" ?
Es gibt noch wesentlich mehr probleme wenn es um referenzen geht.
Das php-manual hat einen eigenen artikel darüber was referenzen nicht
sind. Wenn ich als entwickler code schreibe und stundenlang suchen
muss warum es nicht funktioniert und sich als grund unlogisches verhalten
der sprache heraus stellt bin ich mehr als frustriert. Aber sicher gibt
es auch ubercoder die sich über soetwas freuen, weil ihnen logik zu langweilig
ist.

Es heißt ganz einfach, dass eine Verbesserung der bestehenden Programmiertechniken nicht dadurch möglich ist, dass man die Syntax ändert.

Nein aber man kann zumindest mal die guten der verfügbaren techniken
durchdacht zur verfügung stellen.

Auf die man aber ohne Probleme verzichten kann, womit Java rein objektorientiert endet

Nein es ist nicht rein objektorientiert. Java ist eine hybridsprache.

Dass du dich an einen einzigen Nachteil von PHP klammerst?
Ernsthaft, das Verhalten von PHP ist inkorrekt, lässt sich aber durch ein dreifaches Gleichheitszeichen umgehen, womit dieser Nachteil wiederum in den Schatten gestellt wird. (Was natürlich trotzdem nichts daran ändert, dass das Verhalten so sch* ist)

Ich habe lediglich dein argument aufgegriffen und dir gezeigt dass es auch
anders geht.
Das ist bei weitem nicht der einzige nachteil von php.

Sehr subjektiver Vorteil, meinst du nicht?

Ja aber die produktivitätssteigerung die damit einher geht, wird auf einmal
auch ganz objektiv für meinen arbeitgeber zum vorteil.

Auch eines der "Features", die ich in die Kategorie der offenen Klassen packe

Das eine hat mit dem anderen nichts zu tun.

nice-to-have, aber kein must-have, abgesehen davon, dass es in Funktionen gegeben ist

Closures sind in php nur über umwege mittels eval() möglich. Weisst du
was ein closure ist ?

Wozu benötigt?

Man erhält noch mehr freiheit. Durch continuations lassen sich eigene
kontrollstrukturen implementieren und spezialisierte formen der
ausführungssteuerung beispielsweise exceptions.

Solange du keine Beispiele bringst, ist das Argument nutzlos

Ok beweise

#swap idiom (just as easy as this)
x,y = y,x

#or-equal (zuweisung geschieht nur wenn x nicht bereits einen wert hat)
x || = "string"

#ensure abgesicherte codeblöcke
begin 
  #come code
rescue => bang
  #handle exceptions
ensure
  #release resource
end

#variable parameterzahl
def some_func(arg1,arg2,*rest)
end

#builtin regexp (oniguruma engine)
x =~ /some_pattern/

#blocks als idiom dass die implementierung von designpatterns erleichtert
#beispiel visitor pattern
[1,2,3,4].each do |i|
   #do sth with current element
end

#etwas länger, generatoren in ruby (eigentlich werden die nicht gebraucht
#weil ruby echte interne iteratoren kennt
#code stammt [url=http://wiki.rubygarden.org/Ruby/page/show/RubyFromPython]von ruby-garden[/url]
#benutzung von blocks und continuations

class Generator
  def initialize
    do_generation
  end

  def next
    callcc do |here|
      @main_context = here
      @generator_context.call
    end
  end

  private

  def do_generation
    callcc do |context|
      @generator_context = context
      return
    end
    generating_loop    # subclass must implement this method!
  end

  def generate(value)
    callcc do |context|
      @generator_context = context
      @main_context.call(value)    
    end
  end
end

class FibGenerator < Generator
  def generating_loop
    generate(1)
    a, b = 1, 1
    loop do

      generate(b)
      a, b = b, a + b
    end
  end
end

fibber = FibGenerator.new
10.times do
  puts fibber.next    # prints 1, 1, 2, 3, 5, 8, 13, 21, 34, 55
end

Namespaces machen (gerade für Anfänger) vieles komplizierter und sie lassen sich durch OOP leicht emulieren

Solange php keine nested classes unterstützt ist es nicht möglich.
Zeig mir ein gegenbeispiel
Das es komplizierter wird wenn es nicht mehr zu nameclashes kommt
wage ich zu bezeifeln.

Ohne Worte...

Weisst du was duck-typing ist ?

greets

[Slava]

Original geschrieben von closure
Nein es ist nicht rein objektorientiert. Java ist eine hybridsprache.

ich glaube, dass du java mit c++ verwechselst.

gib mir wenigstens ein beispiel wo eine variable oder function(METHODE) in java ohne einen Object existiert.

einizege was man in java nicht in der classe stehen darf, ist nur
"import" Anweisung

[closure]

Hi,

in java muss alles in einer klasse stehen. Selbst die datei wird als
klasse behandelt. Aber nicht alles in java ist ein objekt. Das betrifft
die builtins short,byte,int,long,double,float,char,boolean.
Deswegen ist java nicht rein objektorientiert. Das behauptet java ja auch
nicht von sich.

greets

[Slava]

Original geschrieben von closure
Hi,

Das betrifft
die builtins short,byte,int,long,double,float,char,boolean.
Deswegen ist java nicht rein objektorientiert. Das behauptet java ja auch
nicht von sich.
greets

wenn du schon die eifache Typen als Argument zur deiner Aussage, dass java nicht rein Objectorientiert ist, benutzen willst,
dann kann ich nur Lachen.

wie stellst du dir dann eine rein Objectorientierte Sprache vor?
+,-,/,*,=,.... als Methoden und char, int, .... als Objecte machen?
dann mach das bitte!
für die einfache Typen sind schon vordiefenierte Classen wie Char, Integer,.. schon vorhanden.
Es bleibt dir nur eine Classe Operators mit statischen methoden zu entwickeln.
Dann wirst du in Guinnesbuch als Erfinder der erster rein OO-Sprache eingetragen.

[closure]

Original geschrieben von Slava
wenn du schon die eifache Typen als Argument zur deiner Aussage, dass java nicht rein Objectorientiert ist, benutzen willst,
dann kann ich nur Lachen.

Das ist die definition von "pure objectoriented". Wie ich bereits schrieb,
behauptet das java nicht mal von sich selbst. Warum behauptest du es dann ?

Original geschrieben von Slava
wie stellst du dir dann eine rein Objectorientierte Sprache vor?
+,-,/,*,=,.... als Methoden und char, int, .... als Objecte machen?
dann mach das bitte!

Brauch ich nicht. Es gibt sprachen die das so machen. Eine davon ist ruby.

greets

[ghostgambler]

Original geschrieben von closure
Nein aber weil ich auf einige jahre an erfahrungen im bereich softwareentwicklung
im kommerziellen umfeld zurückblicken kann.

Das lehrt dich jedoch nur den kommerziellen Teil. Ich "arbeite" zwar nur gemeinnützig, aber mindestens eine Website übersteigt von der Request-Anzahl mit Sicherheit, viele viele kommerzielle Websiten (2.5 Mio PIs am Tag, davon träumen einige Websitenbesitzer ^^,)

Hinzu kommt stoff den man erst auf der uni lernt.

Natürlich gibt es da was (was ich auch sehr schade finde, vor allem weil man das Meiste leider nirgends aufarbeiten/finden kann)

Enthusiasmus gleicht keine erfahrung aus.

Durch Enthusiasmus macht man etwas mit den Dingen und erhält so Erfahrung

Ich stemple dich nicht als diskussionsunfähig ab, ich spreche dir lediglich
ein gewisses wissen ab, dass aber für diese diskussion von vorteil wäre.

Von Vorteil, aber nicht notwendig (zumindest bisher nicht)

Das oo-konzept beschreibt einige wesentliche merkmale, die das paradigma
vorteilhaft erscheinen lassen. Bei der konkreten umsetzung gibt es jedoch
unterschiede. Soll heissen bei den sprachlichen mitteln die einem zur
verfügung gestellt werden. Es ist ohne weiteres möglich in C objektorientiert
zu programmieren, Das betrifft beides, sowohl die projektmethodik als auch
die implementierung.
Zunächst kann man sich mal c++ anschauen. C++ als hybridsprache
unterstützt den entwickler mit sprachlichen mitteln um eine bestimmtes
OO-Konzept umsetzen zu können. Aber c++ kennt von haus aus
keine metaobjekte. Es gibt beispielsweise kein class-objekt.
Es gibt neben dem klassenbasierten konzept z.B. auch noch
prototypbasierte oder eben objektbasierte konzepte.
Auch beim message-passing gibt es kleine aber feine unterschiede.
Sicher kann man die verschiedenen methoden emulieren, aber
das design der sprache und die wahl des OO-konzepts lenkt einen
in eine bestimmte bahn.

Dem stimme ich zu; aber im Endeffekt ist doch alles unter dem großen Thema OOP zusammengefasst.

Btw. sind einige features der OOP in php nicht verfügbar.
Etwa multimethods und multiple inheritance. Echte ctors und dtors
gibt es auch nicht. Polymorphie ist nur sehr eingeschränkt möglich.

Du vergisst aber auch, dass PHP erst langsam in Richtung OOP schwenkt. PHP4 war in Sachen OOP praktisch unnutzbar, erst mit PHP5 kamen Features, die die OOP sinnvoll machten; ich erwarte eigentlich, dass da im Laufe der Zeit noch was verbessert wird (aber wer weiß...)

Die irb als interaktiver
rubyinterpreter erlaubt es inkrementel am system zu entwickeln.

Meinst du bei irb nur das einfache Eingeben von Kommandos?
e.g. wie hier benutzt um ruby zu lehren http://www.ruby-lang.org/en/documentation/quickstart/
Vielleicht habe ich das Konzept der interaktiven Shells (Ruby, Python) einfach nicht geblickt, aber abgesehen von einer Spielerei zum Testen der Sprache, konnte ich diese Shells bisher nicht zum Programmieren produktiver Endprodukte nutzen.
Das Einzige wofür diese Shells bisher für mich interessant waren, war die schrittweise Ausführung von Programmcode, mit der Möglichkeit an jedem Punkt ggf. Debug-Ausgaben oder Testroutinen einzufügen. Ein nachträgliches "Speichern" des Programmes, zur Wiederverwendung, war mir bisher fremd.

Inkonsistenzen in der sprache. Orthogonalität der sprachfeatures.

Schau dir doch mal php an.
strstr()
strtok()
strlen()

aber

str_replace()
str_count()
substr_compar()
parse_str()

Das ist wirklich inkonsistent und auch eines der Probleme die ich als inakzeptabel betrachte, gleiches gilt für Reihenfolgen von Parameter, und, noch viel gravierender, Gleichgültigkeit in der Reihenfolge von Parameter (explode/join). Das da bei den sowieso teilweise gravierenden Änderungen mit php6 (magic_quotes, register_globals), nicht auch dabei ein Schlussstrich gezogen wurde, ist mir schleierhaft...

Wenn ich als entwickler code schreibe und stundenlang suchen
muss warum es nicht funktioniert und sich als grund unlogisches verhalten
der sprache heraus stellt bin ich mehr als frustriert. Aber sicher gibt
es auch ubercoder die sich über soetwas freuen, weil ihnen logik zu langweilig
ist.

*schild schwenk* folgendes Argument ist billig, ich wollte es nur mal gesagt haben

Wer sich aber auch auf die dynamische Konvertierung einer kompletten Klasse in einen booleanen Typ verlässt, hat es nicht anders verdient :P
Das sind Punkte, wo ich persönlich die dynamische Konvertierung gen Himmel schieße

if ($obj) {
  // Banane
}

if (is_null($obj)) {
  // besser
} 

Nein aber man kann zumindest mal die guten der verfügbaren techniken
durchdacht zur verfügung stellen.

Der Nachteil von PHP und gleichermaßen Vorteil von Ruby ist, dass PHP eine, nicht ganz hübsche, Vorgeschichte hat...

Nein es ist nicht rein objektorientiert. Java ist eine hybridsprache.

Das war darauf bezogen, was man mit der Sprache macht. Obwohl es eine Hybridsprache bleibt, kann man seinen Code selber als puren OOP-Source schreiben.

Das eine hat mit dem anderen nichts zu tun.

Das kannst du so nicht sagen, immerhin sind beides Ansätze für eine dynamische(re) OOP. Ich bleibe bei der Meinung, dass das System der offenen Klassen, ich als nicht sonderlich gut ansehe.
Das MPO/CLOS sieht in der Theorie recht fein aus (wie praktisch alles in der Theorie immer so gut aussieht ^^), jedoch fürchte ich auch da um eine fehlenden Integrität der geschriebenen Klassen ... aber das ist nur Spekulation, ich werde mir das vor weiteren Äußerungen demnächst erstmal in der Praxis anschauen.

Closures sind in php nur über umwege mittels eval() möglich. Weisst du
was ein closure ist ?

Sry, hatte den Artikel gestern in den 5 Minuten Pausen zwischen einer Serie gelesen und dabei wohl das wichtigste überlesen ^^;
Du hast natürlich recht, php bietet das nicht wirklich... Allerdings muss ich dazu sagen, dass ich das bisher auch noch nicht vermisst habe

Man erhält noch mehr freiheit. Durch continuations lassen sich eigene
kontrollstrukturen implementieren und spezialisierte formen der
ausführungssteuerung beispielsweise exceptions.

Das ist eine se~hr abstrakte Antwort auf meine Frage.
Exceptions sind und sollten in jeder besseren objektorientierten Sprache vorhanden sein (ich hoffe doch in Ruby auch? Ansonsten hat PHP da doch tatsächlich sprachlich mal die Nase vorn ^^)
Und die Diskussion um abstrakte Kontrollstrukturen, als Ersatz für bereits vorhandene, ist an dieser Stelle spätestens nach den schon Jahre andauernden Diskussionen um GOTO, hinfällig; deshalb gehe ich da nicht weiter drauf ein

#blocks als idiom dass die implementierung von designpatterns erleichtert
#beispiel vistior pattern
[1,2,3,4].each do |i|
   #do sth with current element
end

#etwas länger, generatoren in ruby (eigentlich werden die nicht gebraucht
#weil ruby echte interne iteratoren kennt
#code stammt [url=http://wiki.rubygarden.org/Ruby/page/show/RubyFromPython]von ruby-garden[/url]
#benutzung von blocks und continuations

class Generator
  def initialize
    do_generation
  end

  def next
    callcc do |here|
      @main_context = here
      @generator_context.call
    end
  end

  private

  def do_generation
    callcc do |context|
      @generator_context = context
      return
    end
    generating_loop    # subclass must implement this method!
  end

  def generate(value)
    callcc do |context|
      @generator_context = context
      @main_context.call(value)    
    end
  end
end

class FibGenerator < Generator
  def generating_loop
    generate(1)
    a, b = 1, 1
    loop do

      generate(b)
      a, b = b, a + b
    end
  end
end

fibber = FibGenerator.new
10.times do
  puts fibber.next    # prints 1, 1, 2, 3, 5, 8, 13, 21, 34, 55
end

Die ersten 3 Idiome, waren okay (Pluspunkt für Ruby, auch wenn sich Äquivalente in PHP finden lassen würden; rein theoretisch, über den Sinn lässt sich streiten und ich sehe es auch mehr als Murks)
Beim Zitierten überwiegt dann doch die Unverständlichkeit. Da ist die Ableitung von SPL in PHP wesentlich hübscher gemacht, die Continuations sind an der Stelle richtig scheußlich...

Solange php keine nested classes unterstützt ist es nicht möglich.
Zeig mir ein gegenbeispiel

Namensgebung mit Unterstrichen ... ich weiß, dass es billig ist, aber es funktioniert. Und Namespaces sind im Endeffekt auch nichts anderes + Automatismus *zucks*

Das es komplizierter wird wenn es nicht mehr zu nameclashes kommt
wage ich zu bezeifeln.

Das Problem der vielen neuen Scopes, ganz einfach. Für viele Anfänger sind die Scopes sowieso ein Buch mit sieben Siegeln, wenn dann noch Namespaces dazukommen...

Weisst du was duck-typing ist ?

Ja, aber ich verstehe nicht was daran so toll sein soll und/oder wieso es ein Vorteil von Ruby gegenüber PHP sein kann/ist?



Das Textfeld von diesem Forum ist übrigens viel zu klein! ... *css änder*

[wahsaga]

Original geschrieben von ghostgambler
Du vergisst aber auch, dass PHP erst langsam in Richtung OOP schwenkt. PHP4 war in Sachen OOP praktisch unnutzbar, erst mit PHP5 kamen Features, die die OOP sinnvoll machten; ich erwarte eigentlich, dass da im Laufe der Zeit noch was verbessert wird (aber wer weiß...)

Was das angeht befürchte ich - und du beschreibst es etwas später ja auch selber - dass da notwendige, weh tuende Einschnitte schlicht und einfach auf dem Altar der Abwärtskompabilität geopfert werden.

Die systemimmanenten "Fehler" und groben Inkonsequenzen von PHP wären nur durch eine konsequente Neuorientierung in einigen Bereichen zu beheben - was der Abwärtskompabilität aber den Genickschuss geben würde.

Ich persönlich würde es begrüßen, wenn PHP 6 (oder sonstige nachfolgende Version) einen solchen radikalen Schnitt machen würde - auch wenn dann in PHP 4/5 geschriebene Scripte nicht mehr ohne umfangereichere Anpassungen lauffähig wären. Wer nicht adaptieren will, müsste dann halt auf dem Level von PHP 5 bleiben.

Aber ich denke, zu einem Schritt mit solch weitreichenden Konsequenzen wird den PHP-Entwicklern der Mut fehlen.

[jahlives]

Warum gilt FALSE == "" == "0" ?

Sorry, dass ich hier auch noch meinen Senf dazu geben muss, aber was hast du denn dagegen, dass man in PHP eben === verwenden sollte, wenn man solchen Problemen aus dem Weg gehen will ?
Das TypeCasting finde ich ehrlich gesagt eine nette Sache. Klar gemäss einer richtigen Programmiersprache nicht korrekt, aber für eine Sprache wie PHP doch genau richtig.
Wie sehr man sich an dieses Casting gewöhnt hat sieht man schnell wenn man seine ersten Schritte in Java oder C++ macht. Klar es ist definitiv sauberer wenn eine Var einen Type bekommt und dieser nicht geändert werden kann.
Zum Thema Java: Also nur weil es 8 primitive Datentypen gibt, die nicht Objekte sind, würde ich Java trotzdem noch als Objekt Sprache bezeichnen. Es versteht sich doch von selbst, dass diese Datentypen keine Objekte sein sollten, denn Objekte kann der Programmierer selber an die Bedürfnisse anpassen. Wobei es ziemlich sicher keinen Sinn machen würde selber ein Boolean Objekt zu definieren
Und trotzdem hat Java für diese Datentypen Wrapper Klassen um solch primitive Datentypen in Objekte zu überführen.

byte  Byte  
short  Short  
int  Integer  
long  Long  
float  Float  
double  Double  
char  Character  
boolean  Boolean

Gruss

tobi