Das deutsche Python-Forum

@NoPy: ich habe den Eindruck, dass Du noch nie wirkliche Tests geschrieben hast. Konzeptionelle Fehler findet man mit Testcases auch nicht.

NoPy hat geschrieben:In statisch typisierten Sprachen muss ich aber eben nicht auf Schnittstellen testen, ganz einfach.

In Python wird auch nicht die Schnittstelle getestet, sondern nur, ob sinnvolle Eingaben sinnvolle Ergebnisse liefern und falls gefordert, ob unsinnvolle Eingaben sinnvolle Fehlermeldungen.

Hyperion hat geschrieben:

NoPy hat geschrieben: Natürlich habe ich Tests gemacht und natürlich sind gelegentlich dabei auch kleinere Fehlerchen aufgetreten. Aber keine nennenswerten konzeptionellen, warum auch.

Öh... das kann ich nicht glauben, oder wir sind doch wieder bei extrem kleinen Programmen! Die Art der Typisierung hat gemein hin nichts mit fachlicher oder technischer Konzeption zu tun Insofern ist das bei allen Sprachen *gleich schwer* und vor allem gleich Fehler anfällig!

Noch mal: Ich weiß, dass statische Typisierung nichts mit dem Konzept zu tun haben. Es erleichtert nur das Arbeiten, weil man sich eben darum nicht zu kümmern braucht.
Es ist eben eine erzwungene Definition eines Schnittstellenbestandteiles. Aber wie gesagt, das ist Wurst, in python ist es halt nicht so. Und gut.

Die Konzeptionierung findet doch normalerweise VOR der Erstellung des Programmes statt. Wenn es fertig ist, muss man nur noch umsetzen. Da sich die meisten meiner letzen Anwendungen auf Datenbanken bezogen (im Wesentlichen auf Oracle) und dadurch schon einiges an Rahmen vorgegeben war, war das keine Hexerei. Es waren eher Details, an denen man verschiedene Varianten ausprobiert hat.
Ich hatte zumindest nicht das Gefühl, dass es sich bei meinen/unseren Programmen um Mikro- Programme gehandelt hat. Woran machst Du das fest? An Quellzeilen? An Mannjahren? An Funktionalitäten? Tut mir leid, bislang war das Konzept wirklich selten mein Problem. Vielleicht auch deshalb, weil ich auf das Konzept idR frühzeitig Einfluss hatte.
Die meisten Sorgen hatte ich wirklich damit, Fremdmodule einzubinden und auszuprobieren, wie diese funktionieren - gerade deshalb, weil eben nicht immer das dokumentiert war, was ich wissen wollte. Wie ich meinen Mist baue, weiß ich schon - zumindest, was die Werkzeuge anging, mit denen ich seit Jahren/Jahrzehnten zu tun hatte.

Also da frage ich mich schon, ueber was fuer Programme wir hier reden. In meiner Praxis (hauptsaechlich Python, Java, C++, also unabhaengig vom Typsystem) hat so gut wie nie ausser fuer triviale Skripte eine Planung am gruenen Tisch eine dauerhafte Grundlage geliefert.

Was nicht heissen soll, dass man planlos drauf los programmieren soll. Aber Softwareentwicklung ist doch grundsaetzlich ein iteratives Geschaeft - und da veraendern sich Anforderungen an Komponenten/Architektur, die eben *nicht* vorher antizipiert werden konnten.

Und wenn du gleichzeitig das Beduerfnis verspuerst, Dritthersteller-Software weg zu abstrahieren, weil du sie austauschen musst/willst, dann haben deine Programme doch offensichtlich auch Zyklen in ihrer Entwicklung.

Dabei hast du noch nie erlebt, dass Konzepte adaptiert werden mussten?

pillmuncher hat geschrieben:

NoPy hat geschrieben:Ganz ehrlich habe ich erwartet, dass mich die interne Implementation nicht interessieren muss. Wenn ich 2 mal hintereinander in ein Objekt hineinsehe, dann hätte ich gern 2 mal das gleiche Ergebnis. Ob dazu erneute eine Netzwerkverbindung etabliert werden muss oder was auch immer wäre mir egal...

Du möchtest also eine Garantie in der Programmiersprache dafür, dass die Daten, die ein anderer Computer über das Netz schickt, jedesmal dieselben sind, wenn du zu ihm eine Verbindung aufbaust. Ok.
Angenommen, die Daten stammen von einer Benutzereingabe, sagen wir aus einem Chat-Programm. Dann möchtest du also eine Garantie in der Programmiersprache dafür, dass ein anderer Benutzer immer dieselben Sachen eintippt, wenn dein Programm das so vorsieht. Ja, klar.

Nein, da hab ich mich wohl missverständlich ausgedrückt. Ich erwarte das nicht von der Programmiersprache, sondern ich hätte mir das vom Entwickler gewünscht.
Für mich existiert durchaus ein Unterschied zwischen einem Chat oder Daten, die über das Netzwerk fließen und einer Excel- Tabelle. Rein von der Nutzung sind Excel- Dateien nicht so gedacht, dass mehrere gleichzeitig an diesen arbeiten (ich weiß, dass es geht. Aber es ist keinerlei Rechtemanagement und Transaktionsprotokoll implementiert. Excel macht bei Kollisionen das, was es für vernünftig hält). Somit ist Excel für mich tatsächlich etwas, was sich nur dann ändern sollte, wenn ICH es ändere. Daher hätte ich etwas anderes erwartet, als einen Generator/Iterator o.ä. Aber wie gesagt, das ist abgehakt.

pillmuncher hat geschrieben:Was du außerdem übersiehst, ist dass das Ergebnis tatsächlich immer dasselbe ist. Du hast einen Iterator, also ein Objekt mit einem internen Zustand, und wenn der abgearbeitet ist, hast du immer noch denselben Iterator, nur mit einem anderen internen Zustand. Iteratoren funktionieren in allen mir bekannten Sprachen auf genau diese Weise. Wenn du unbedingt willst, dass Objekte keine internen veränderlichen Zustände haben, musst du in einer Sprache programmieren, die das sicherstellt. Haskell etwa.

NoPy hat geschrieben:ich brauch keinen Schwanzlängenvergleich zwischen python und irgend einer anderen Programmiersprache.

Wenn ich eine Frage der Form:
Wie mache ich etwas, das in BlaBlaBla so geht, mit python?

Dann fände ich folgende Arten von Antworten chic:
1. Das geht so:
2. Das macht man in python ganz anders, nämlich:
3. Das geht in python gar nicht. Lass Dir etwas anderes einfallen.

Wenn du ein konkretes Problem hast, kann man konkret helfen. Deine Problembeschreibungen sind aber viel zu abstrakt, um konkret beantwortet zu werden.

Achja: Schwanzlängenvergleich. Liest du eigentlich, was ich schreibe? Ich habe nirgends behauptet, Python sei viel superer als alle anderen Sprachen. Ich habe mich lediglich über Bondage & Discipline Sprachen lustig gemacht, aber auch das ist kein Schwanzlängenvergleich. Überall sonst habe ich darauf hingewiesen, dass die genannten Probleme alle genannten Sprachen betreffen. Das ist ein toller Schanzlängenvergleich, wo der Vergleicher sagt: "Hey, meine Sprache ist die superste von allen, weil sie genauso funktioniert, wie alle anderen."

Es tut mir leid, wenn ich einen Nerv getroffen habe, das wollte ich nicht. Ich fand deine Antworten völlig in Ordnung, das ist ein klares Danke Schön.

__deets__ hat geschrieben:Also da frage ich mich schon, ueber was fuer Programme wir hier reden. In meiner Praxis (hauptsaechlich Python, Java, C++, also unabhaengig vom Typsystem) hat so gut wie nie ausser fuer triviale Skripte eine Planung am gruenen Tisch eine dauerhafte Grundlage geliefert.

Tut mir leid, aber das sollte sie schon.

__deets__ hat geschrieben:Was nicht heissen soll, dass man planlos drauf los programmieren soll. Aber Softwareentwicklung ist doch grundsaetzlich ein iteratives Geschaeft - und da veraendern sich Anforderungen an Komponenten/Architektur, die eben *nicht* vorher antizipiert werden konnten.

Natürlich. Aber auch dafür steht das Konzept, das umzusetzen ist, BEVOR man mit der Umsetzung anfängt. Wenn man es am grünen Tisch nicht entscheiden kann, dann bietet sich ein Prototyping an. Und das habe ich in der Regel so quick and dirty programmiert, dass ich gar nicht nachnutzen möchte. Das Ziel vom Prototyping ist ja, dass man sich anhand dessen abstimmen kann. Und natürlich gibt es da auch punktuell Dinge/Objekte etc., die angepasst werden müssen. Aber ein Auto bleibt ein Auto, bislang war es höchst selten, etwas zu verändern, was nicht durch erweitern zu lösen war. Aber wie gesagt, mag sein, dass mein Betätigungsumfeld anders ist. Ich schreibe Datenbanksoftware. Es ist teuer, diese Daten zu erheben, daher tut man sich schwer damit, die Strukturen der Daten umzuwälzen, weil entweder eine Migration danach nicht möglich ist - Datenverlust - oder eine Migration möglich ist - dann ist der Umbau oft unnötig.

__deets__ hat geschrieben:Und wenn du gleichzeitig das Beduerfnis verspuerst, Dritthersteller-Software weg zu abstrahieren, weil du sie austauschen musst/willst, dann haben deine Programme doch offensichtlich auch Zyklen in ihrer Entwicklung.

Dabei hast du noch nie erlebt, dass Konzepte adaptiert werden mussten?

Natürlich müssen an einer Software im Laufe des Lebens dieser Anpassungen vorgenommen werden. Beispielsweise, weil sich Datenbank- oder Betriebssystem- Versionen ändern. Aber bislang mussten noch keine Konzepte in Größenordnungen angepasst werden. Wie gesagt, ich bilde eine relativ steife Realität ab. Änderungen an dieser haben Laufzeiten von Jahrzehnten. Wenn Dinge also einmal etabliert sind, dann müssen sie meist nur erweitert werden.

Also da scheinst du in einer sehr speziellen Ecke des Softwareentwicklungskosmos zu residieren.

Denn dein Vergleich mit Auto-Konstruktion hinkt in meinen Augen sehr, und ist auch der Grund dafuer, warum viele Leute nicht verstehen, wieso Softwareentwicklung eine dermassen schlecht planbare Kunst ist - statt schoen ingenieurswissenschaftlich Standardloesungen fuer Standardkomponenten zu verschrauben.

Der Grund liegt in meinen Augen darin, dass die Konnektivitaet deutlich geringer ist - eine Kupplung haengt an einer Seite am Motor, und an der anderen am Getriebe. Aber niemals am Schiebedach. In der Softwareentwicklung ist das jedoch gang & gaebe.

Wenn dein Job hauptsaechlich aus DB-Entwurf besteht - da bin ich bei dir. Unser Datenmodell hat sich verhaeltnismaessig wenig entwickelt in den letzten Jahren.

Aber wenn man etwas anderes als nur simpelste Masken zur Betrachtung & Bearbeitung vorsieht - dann kann man schon mal gezwungen sein, fuer die Integration eines neuen Payment Anbieters weite Teile des Codes umzuwerfen, weil der Seitenfluss nicht mehr derselbe ist - ohne dabei einen Fehler beim urspruengliche Konzept gemacht zu haben. Gab halt noch kein PayPal.

Genauso hat die Einfuehrung von Hardware statt reinen Software Verkaeufen inklusive der Notwendigkeit, Vorbestellungen aufzugeben, abzuarbeiten, zu widerrufen, Einfluss auf all den bestehenden Code, und da muss dann schon nachgebessert werden.

Mit anderen Worten: das Auto lernt schwimmen und fliegen, und ist kein Auto mehr, sondern ein FliWaTüt, und das natuerlich nicht durch Neukonstruktion, sondern refactoring.

__deets__ hat geschrieben:Also da scheinst du in einer sehr speziellen Ecke des Softwareentwicklungskosmos zu residieren.

Wahrscheinlich schon, denn die meisten meiner "Objekte" sind echte, darunter einige, die mit Sicherheit die Lebenszeit der virtuellen überdauern (z.B. Bäume).
Natürlich hängen an diesen Objekte dran, die sich gelegentlich ändern, je nach Vorschriften/Regeln etc. Aber auch das hält sich in Grenzen.

__deets__ hat geschrieben:Denn dein Vergleich mit Auto-Konstruktion hinkt in meinen Augen sehr, und ist auch der Grund dafuer, warum viele Leute nicht verstehen, wieso Softwareentwicklung eine dermassen schlecht planbare Kunst ist - statt schoen ingenieurswissenschaftlich Standardloesungen fuer Standardkomponenten zu verschrauben.

Vor ca. 15 Jahren habe ich mich mal mit Metriken zur Berechnung des zu erwartenden Entwicklungsaufwandes beschäftigt. Es geht schon, aber den Aufwand betreibt halt keiner mehr, weil alles schnell gehen muss. Es wird eher grob ins Blaue geschätzt, als wirklich vorher die TippelTappelTour Lastenheft - Pflichtenheft - Lastenheft - Pflichtenheft ... durchzugehen, nicht zuletzt, weil Softwareprojekte oft ausgeschrieben werden müssen. Oft wird dann soviel geliefert, wie zu diesem Preis gefertigt werden kann. Den Rest macht die 90/10- Regel (90% des Aufwandes schafft man in 10% der Zeit, für die restlichen 10% benötigt man 90% der Zeit. Wenn man also 45% des Aufwandes bezahlt bekam, kann man 90% + 35/90*10% liefern, also in etwa 94%. Die restlichen versteckt man dann dahinter, dass der Kunde sich etwas anders überlegt hat und muss sie nie umsetzen oder bekommt sie indirekt bezahlt.

Mein Glück ist, wie gesagt, dass ich in die Konzeptionsphase eingebunden war, so dass einerseits ich schneller begreifen konnte, was erwartet wurde, und andererseits der Kunde gleich eine Aufwandsabschätzung mitbekommen konnte. Aber jetzt bin ich sowieso in einer anderen Situation. Ich programmiere nur noch für mich, gewissermaßen zum Spaß, um meine Arbeit effektiver zu machen. Ich beschaffe Informationen aus Daten, die nur aus den Ecken herausgekratzt werden können. Meine Projekte sind jetzt keine eigentlichen Software- Projekte mehr. Dennoch lassen sich die meisten Dinge nur effizient lösen, wenn man algorithmisch an die Sache herangeht.

Und daher brauche ich einen Satz spezifisches Werkzeug, das ich schnell zu einem Roboter bauen kann, der quasi die Eingangsdaten besorgen, mit Datenbankdaten verschneiden und die Ausgangsdaten herausbrechen kann. Die Aufgabenstellungen sind immer unterschiedlich, die benutzten "Schnittstellen" im weiteren Sinne aber meist die gleichen, wenn auch oft unterschiedliche Aspekte zum Tragen kommen.

__deets__ hat geschrieben:Der Grund liegt in meinen Augen darin, dass die Konnektivitaet deutlich geringer ist - eine Kupplung haengt an einer Seite am Motor, und an der anderen am Getriebe. Aber niemals am Schiebedach. In der Softwareentwicklung ist das jedoch gang & gaebe.

Na ja, bei mir halt nicht. Um bei dem Modell zu bleiben: Es ist für mich kein Problem, das Auto zum fliegen zu bringen, schließlich habe ich es ja selbst gebaut. Mein Problem ist, dass ich Himmel und Erde von anderen benutze. Da brauche ich nur wenige Schnittstellen, die Farbe des Himmels und die Temperatur sind mir egal, dafür muss ich aber unkompliziert auf die Position der Wolken zugreifen können, und zwar immer wieder und eigentlich immer nur die Wolken. Falls mich Hubschrauber je interessieren sollten, müsste ich meine Schnittstelle zum Himmel erweitern.

So habe ich im Grunde über Jahre entwickelt, das war kein Problem. Und selbst, wenn ich meine Himmel- Schnittstelle nur alle 3 Jahre benutzt habe, musste ich keine Dokumentation lesen, weil die Schnittstelle selbsterkärend und selbstüberwachend war. Letzteres bekomme ich bei Python halt nicht, ist aber auch nicht so schlimm. Ich muss jetzt eben lernen, wie ich mir meine Werkzeuge mit python so baue, dass ich sie immer wieder so benutzen kann, wie ich sie benötige.

__deets__ hat geschrieben:Wenn dein Job hauptsaechlich aus DB-Entwurf besteht - da bin ich bei dir. Unser Datenmodell hat sich verhaeltnismaessig wenig entwickelt in den letzten Jahren.

Noch nicht einmal Entwurf, sondern nur mit komplexen Auswertungen.

__deets__ hat geschrieben:Aber wenn man etwas anderes als nur simpelste Masken zur Betrachtung & Bearbeitung vorsieht - dann kann man schon mal gezwungen sein, fuer die Integration eines neuen Payment Anbieters weite Teile des Codes umzuwerfen, weil der Seitenfluss nicht mehr derselbe ist - ohne dabei einen Fehler beim urspruengliche Konzept gemacht zu haben. Gab halt noch kein PayPal.

Genauso hat die Einfuehrung von Hardware statt reinen Software Verkaeufen inklusive der Notwendigkeit, Vorbestellungen aufzugeben, abzuarbeiten, zu widerrufen, Einfluss auf all den bestehenden Code, und da muss dann schon nachgebessert werden.

Mit anderen Worten: das Auto lernt schwimmen und fliegen, und ist kein Auto mehr, sondern ein FliWaTüt, und das natuerlich nicht durch Neukonstruktion, sondern refactoring.

Das ist schon richtig, in solchen Fällen ändert sich das Design ständig. Ich habe keine Ahnung, ob man dafür dann irgend etwas wie agile Programmierung oder extreme programming benutzen sollte, aber dazu habe ich auch nur mal was gelesen, ich habe es nie gebraucht.