Dynamische Sprachen

[Shade Of Mine]

Mechanics schrieb:

Und wenn ich ein Problem lösen muss, dann komm ich zu 99% auf einen rein objektorientierten Ansatz. Ich brauche da kein duck typing etc.

Ducktyping kann aber ein OOP Ansatz sein.
Deine Argumentation macht irgendwie keinen Sinn...

C++ Templates sind zB ducktyping!

[Mechanics]

Shade Of Mine schrieb:

Mechanics schrieb:

Und wenn ich ein Problem lösen muss, dann komm ich zu 99% auf einen rein objektorientierten Ansatz. Ich brauche da kein duck typing etc.

Ducktyping kann aber ein OOP Ansatz sein.
Deine Argumentation macht irgendwie keinen Sinn...

C++ Templates sind zB ducktyping!

Aber statisch, zur Kompilierzeit. Das kann durchaus ins Konzept passen. Da ist nichts dynamisches, wo man an tausend Stellen aufpassen muss, was genau jetzt passiert, weil jemand was vergessen oder sich vertippt hat.
Im Grunde sage ich nichts gegen Python. Es gibt Menschen, die mögen dynamisch typisierte Sprachen, und es gibt Menschen, die mögen sie nicht. Ich gehör einfach zu den letzteren.

[Shade Of Mine]

Ich kapier die argumentation einfach nicht. Mal ists gut, mal ists schlecht.

[Zeus]

Shade Of Mine schrieb:

Ich kapier die argumentation einfach nicht. Mal ists gut, mal ists schlecht.

Weil statisches Ducktyping > dynamisches Ducktyping

[dgf5g5r]

Shade Of Mine schrieb:

Ich mag Python sehr. Die Libraries sind etwas strange, aber sonst ganz nett das Ding.

Was waren die größten Projekte die du mit Python gemacht hast? Wieviele Mannmonate arbeit?

[Shade Of Mine]

Zeus schrieb:

Shade Of Mine schrieb:

Ich kapier die argumentation einfach nicht. Mal ists gut, mal ists schlecht.

Weil statisches Ducktyping > dynamisches Ducktyping

Und genauso ist starke typisierung > starke typisierung.
verstehe. macht sinn.

Ich finde es lustig wie die Argumentation sich immer wandelt wenn man neue Informationen in die Diskussion einbringt Meistens werden nur Argumente gesucht um Sprache A besser darzustellen als Sprache B.

Dass es dabei aber einfach nur um Konzepte geht - und zB einige Sprachen deshalb the-best-of-both-worlds(tm) habe, wird dann gerne ignoriert. C# hat zB extra dynamische typisierung eingebaut - weil dynamische typisierung super ist. Das "Problem" ist type checking zur Laufzeit. Aber das tut man in sprachen wie C# und Java sowieso oft genug.

PS: als kleiner Lesestoff: http://www.artima.com/intv/typing.html

[Zeus]

Shade Of Mine schrieb:

Zeus schrieb:

Shade Of Mine schrieb:

Ich kapier die argumentation einfach nicht. Mal ists gut, mal ists schlecht.

Weil statisches Ducktyping > dynamisches Ducktyping

Und genauso ist starke typisierung > starke typisierung.
verstehe. macht sinn.

Nein du verstehst nix und dein Post macht ingesamt kein Sinn.

[buchstaben]

Da ist nichts dynamisches, wo man an tausend Stellen aufpassen muss, was genau jetzt passiert, weil jemand was vergessen oder sich vertippt hat.

daß bei dynamischer Typisierung Typfehler vorkommen können, die erst zur Laufzeit offenbar werden, ist in der Theorie zwar nachteilig, die Frage ist aber, wie groß dieses Problem in der Praxis ist.

ich habe beruflich in python programmiert und einige Privatprojekte in verschiedenen dynamischen Sprachen, und ich kann mich nach ein paar Stunden der Umgewöhnung (vorher nur C, Pascal, C++) an kaum einen Laufzeit-Typfehler erinnern, obwohl es am ersten Vormittag mit python vermutlich eine handvoll solcher Fehler gegeben hat, an die ich mich nicht mehr erinnere.

man gewöhnt sich beim Programmieren zweierlei an: 1. vor dem Hinschreiben von bla.foo() zu überlegen, ob bla von einer Klasse ist, die auf foo() antwortet - 2. sprechende Variablen- und Klassennamen, sodaß ein Typfehler wie grundfarbe.anzahl_beine() auch ohne Fehlermeldung vom Compiler ins Auge stechen würde.

[123456789098765]

Shade Of Mine schrieb:

Zeus schrieb:

Shade Of Mine schrieb:

Ich kapier die argumentation einfach nicht. Mal ists gut, mal ists schlecht.

Weil statisches Ducktyping > dynamisches Ducktyping

Und genauso ist starke typisierung > starke typisierung.
verstehe. macht sinn.

Ich finde es lustig wie die Argumentation sich immer wandelt wenn man neue Informationen in die Diskussion einbringt Meistens werden nur Argumente gesucht um Sprache A besser darzustellen als Sprache B.

So ein Quatsch. Irgendwie war doch von anfang an klar, was Mechanics meint, auch wenn er flasche Begriffe wie "richtige Objektorientierung und stark typisierte Sprachen" verwendet hat. Die Argumentation hat sich nie geändert. Bist du auch so "dumm" wenn du mit Kunden redest und bekommst es nicht hin rauszuhören, was sie wollen oder stellst du dich nur hier so?

[Mechanics]

Shade Of Mine schrieb:

Zeus schrieb:

Shade Of Mine schrieb:

Ich kapier die argumentation einfach nicht. Mal ists gut, mal ists schlecht.

Weil statisches Ducktyping > dynamisches Ducktyping

Und genauso ist starke typisierung > starke typisierung.
verstehe. macht sinn.

Ich finde es lustig wie die Argumentation sich immer wandelt wenn man neue Informationen in die Diskussion einbringt

Nein. Ich habe den Begriff "starke Typisierung" erst falsch verwendet, weil ich nicht auf meine Wortwahl geachtet habe. Dann kamen Aussagen wie "Python ist doch stark typisiert". Ja, ist es. Es ist dynamisch und stark typisiert. Macht für mich keinen Sinn. Wenn schon, dann stark statisch typisiert, das ist das was ich bevorzuge und was ich die ganze Zeit sagen wollte.
Aber WENN schon eine dynamische Scriptsprache, und da spricht ja schon mal nichts dagegen, weil natürlich schreibe ich auch immer wieder mal kleinere und mittelgroße Scripte, dann will ich eine wirklich dynamische Sprache haben, mit der ich ein kleines überschaubares Programm elegant hinschreiben kann. Was sollte starke Typisierung denn in dem Kontext für einen Vorteil haben? In dem Fall sorgt es nur für Boilerplate Code.

@buchstaben: Ich finde, das ist nicht nur in der Theorie ein Problem, das ist auch in der Praxis ein unglaubliches Riesenproblem, das gern totgeschwiegen wird. Ich habe schon in etlichen Firmen sehr viele Probleme gesehen, die Wochen Zeit gekostet haben, und die bei einfachen Compilerüberprüfungen nicht entstanden wären. Und welche Vorteile soll es jetzt genau bringen, diese Überprüfungen wegzulassen? Ich sehe keine. Bei einem Script mit unter 1000 Zeilen kein Problem, aber bei allem was drüber hinausgeht, tut man sicher meiner Meinung nach damit keinen Gefallen.

Ich will Python nicht schlecht darstellen. Für mich persönlich überwiegen bei dynamischen Scriptsprachen die Nachteile die Vorteile deutlich. Das ist meine subjektive Meinung, wenn jemand was größeres in Python programmieren will, ich halte keinen davon ab.

[Shade Of Mine]

Mechanics schrieb:

Aber WENN schon eine dynamische Scriptsprache, und da spricht ja schon mal nichts dagegen, weil natürlich schreibe ich auch immer wieder mal kleinere und mittelgroße Scripte, dann will ich eine wirklich dynamische Sprache haben, mit der ich ein kleines überschaubares Programm elegant hinschreiben kann. Was sollte starke Typisierung denn in dem Kontext für einen Vorteil haben? In dem Fall sorgt es nur für Boilerplate Code.

"wirkliche OOP", "wirkliche dynamische Sprache"

[kantaki]

Ich finde Python sehr elegant und viel schöner als andere Sprachen wie ruby oder lua etc.
Eins stört mich aber , und das ist "Fehler erst bei Laufzeit". Ich verstehe den Vorteil noch nicht ganz.

zb

def some_function(x):

...

x = 123
some_f:Dnction(x)

Gibt es eine IDE die solche Fehler erkennt ?

[Mechanics]

kantaki schrieb:

Gibt es eine IDE die solche Fehler erkennt ?

Schwierig, weil die Sprache eben dynamisch ist. Die Funktion könnte von sonst woher kommen. Du kannst auch dynamisch Funktionen definieren und hinzufügen. Aber wenn die IDE gute Unterstützung für die Programmiersprache bietet, sollten sich solche Fehler in Grenzen halten lassen. Probier mal Eclipse, bin mir nicht sicher, obs was bessser gibt.
Das ist eben das Problem, das ist angesprochen habe. Viele Fehler, die der Compiler zur Kompilierzeit erkennen könnte, fallen erst irgendwann zur Laufzeit auf. Und es gibt noch viel vertracktere Fehler, als das.

[kantaki]

Mechanics schrieb:

kantaki schrieb:

Gibt es eine IDE die solche Fehler erkennt ?

Schwierig, weil die Sprache eben dynamisch ist. Die Funktion könnte von sonst woher kommen. Du kannst auch dynamisch Funktionen definieren und hinzufügen. Aber wenn die IDE gute Unterstützung für die Programmiersprache bietet, sollten sich solche Fehler in Grenzen halten lassen. Probier mal Eclipse, bin mir nicht sicher, obs was bessser gibt.
Das ist eben das Problem, das ist angesprochen habe. Viele Fehler, die der Compiler zur Kompilierzeit erkennen könnte, fallen erst irgendwann zur Laufzeit auf. Und es gibt noch viel vertracktere Fehler, als das.

Ich denke ich werde pycharm benutzen, da ich sowieso in Richtung Webdevlopment gehen möchte.

http://www.jetbrains.com/pycharm/features/index.html

Sieht sehr sehr gut aus. Kostet allerdings auch 28€, sollte ich aber verkraften

[Mechanics]

Ich kenne PyCharm nicht, aber ich finde, Jetbrains macht gute Software.

[cooky451]

Ich muss sagen die Fehlerfindung zur Laufzeit hat mich in Python auch sehr genervt. In C++ setze ich alles daran viel zur Compilezeit abzufangen, und Python geht genau den anderen Weg. Das einzige "Größere" (war immernoch total klein, 2 Leute halt) das ich gezwungenermaßen mit Python machen musste, hat mich total genervt. Das geht schon los mit so Kleinigkeiten wie

blubb = xyz
#...
def foo():
  blubb = 4
  #...

Wurde dann zu

blubba = xyz
#...
def foo():
  blubb = 4
  #...

Aber das gibt natürlich keinen Compilerfehler, weil hier einfach eine neue Variable angelegt wird. Bis ich den ganzen Kram wieder raus hatte. Argh. Und geht weiter mit irgendwelchen total kryptischen Fehlern, die alle nur aus Flüchtigkeitsfehlern resultierten, die ein statisches Typsystem sofort aufgefangen hätte. Vielleicht hab ich die Sprache einfach nie ordentlich gelernt, aber mich hat sie nur genervt sobald man 200+ Zeilen hatte.

(Von dem Quatsch mit der erzwungenen Einrückung fang ich gar nicht erst an.)

[buchstaben]

erzwungene Einrückung ist doch sinnvoll, weil es Redundanz vermeidet. Eingerückt wird ja sowieso, auch in Sprachen mit { ..... } oder BEGIN ... END, wo es eigentlich gar nicht nötig wäre.

80 Zeichen/Zeile reichen bei 4er Tab für Einrücktiefen bis 19, das dürfte selbst für üblen Spaghetticode ausreichen.

ad Flüchtigkeitsfehler: es kann doch ganz heilsam sein, wenn man beim Programmieren mit dynamischen Sprachen gezwungen wird, sich bei jedem Bezeichner zu überlegen, ob er korrekt hingeschrieben wurde, ob die Klasse den betreffenden Methodenaufruf auch unterstützt usw ... und sich nicht drauf zu verlassen "der Compiler findet die Flüchtigkeitsfehler ja eh". Abgesehen davon findet der Bytecode-compiler ja auch Fehler, ist ja nicht so, daß man beliebigen Quatsch compilieren könnte. Typfehler zur Laufzeit sind natürlich ein Thema.

[malhören]

Was macht ihr eigentlich mit diesem ganzen dynamischen Möglichkeiten die man mit Python hat? Bitte keine Links zu irgendwelchen theortischen Sachen, sondern das was ihr wirklich macht aufzählen.

[.filmor]

Sich kompliziertere Polymorphieansätze sparen. Ist halt für Prototypen wahnsinnig praktisch, wenn du nicht ständig irgendwelche Zeiger oder Schlauzeiger rumreichen musst oder auch mal schnell an einer einzigen Stelle im Programm den Typ einer Variable ändern kannst ohne dass dir der Rest um die Ohren fliegt.

[malhören]

.filmor schrieb:

Sich kompliziertere Polymorphieansätze sparen. Ist halt für Prototypen wahnsinnig praktisch, wenn du nicht ständig irgendwelche Zeiger oder Schlauzeiger rumreichen musst oder auch mal schnell an einer einzigen Stelle im Programm den Typ einer Variable ändern kannst ohne dass dir der Rest um die Ohren fliegt.

Also eigentlich nur für Hacks.