Programmieren heutzutage = Paste'n Go

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Antworten
madfrog
User
Beiträge: 19
Registriert: Montag 19. Januar 2009, 01:56

Da ich neu hier bin ... kurz zu mir: Ich hab das letzte Mal richtig programmiert so vor ca. 10 Jahren in C++. Damals hat mir dann aber D3D den letzten Nerv geraubt und so habe ich lange Zeit nicht mehr programmiert. Wie gesagt ca. 10 Jahre ist das her. Da ich im Moment leider kein Besitzer einer neueren Version von Microsoft Visual Studio bin, habe ich mich entschieden mich erstmal einer High-Level Scripting Sprache, wie Python, die ja wenigstens kostenlos erhältlich ist, zu widmen. Alleine die Entscheidung für Python fiel mir schwer, da Lua auch nett aussieht, aber leider nicht so gut dokumentiert ist wie Python. Ich hab mich also wieder ein wenig eingearbeitet und muß doch direkt feststellen, daß sich einige Sachen ziemlich gewandelt haben. Und nun möchte ich hier fragen, ob meine Beobachtungen richtig sind.

Mir ist z.B. aufgefallen, daß es eine unüberschaubare Menge an Erweiterungen für Python gibt. So muß man im Endeffekt wirklich keinen Gedankenschmalz mehr lassen, sich irgendwie eigene Lösungen zu basteln, da sie schon irgendwo dadraußen liegen. Einzig die Elemente zusammenzufügen ist noch Aufgabe des Programmierers. Immer wird hier auf irgendwelche Links zu 3rd Party Packages verwiesen, die das Problem dann für einen lösen. Ist das heutzutage so?

Auch C# und Java machen diesen Eindruck. Vor wie gesagt 10 Jahren war Java noch eine Randerscheinung und es war weit davon entfernt Industriestandard zu sein. C# scheint irgendwie, was ich von den Videos auf Microsoft Seiten so sehe, eher ein Baukasten zu sein, wo es im Endeffekt nur darum geht, effektiv zu googlen und den gefundenen Code mehr schlecht als recht zusammen zu pasten. Ist das heutzutage so?

Irgendwie ist es komisch, da ich es halt gewohnt bin, eigene Lösungen zu basteln. Z.B. wird hier viel über Internet Scraping diskutiert. Alleine dafür gibt es vermutlich schon ein dutzend Möglichkeiten, die einen zum Ziel führen. Google hilft bestimmt! Also ist das heutzutage Programmieren? Googlen und dann Paste'n Go?

Ich würde mich freuen, wenn ihr mir sagt, wie ihr das empfindet. Ich hab nur das Gefühl, daß wir damals noch mehr zu Fuß machen mußten als heutzutage.
Benutzeravatar
BlackVivi
User
Beiträge: 762
Registriert: Samstag 9. Dezember 2006, 14:29
Kontaktdaten:

Zuerst einmal: Um C++ zu programmieren musst du nicht das Visual Studio benutzen. Es gibt eine menge vollkommen freie Alternativen für Windows (MinGW) und Linux (GCC). Wenn du aber das Microsoftzeug ganz gerne magst, kannst du auch Visual C++ Express benutzen. Das ist vollkommen kostenfrei und bietet die wichtigstens Sachen um kleine Applikationen zu schreiben. Sogar große Applikationen wie Irrlicht und Ogre benutzen Express, also kann es nicht so stark limitiert sein.

Es gibt außerdem einen riesigen Unterschied zwischen "Ich programmiere indem ich mir Zeug zusammenschreibe" und "ich benutze eine vernünftige Bibliothek um mich auf mein Problem zu konzentrieren". Die Probleme von heute umfassen oft einen ganz anderen Hintegrund als früher. GUI-Programmierung wurde nicht so stark abstrahiert, weil die OS-Schnittstellen zu den Frameworks auch nicht so krass voll waren wie heute.

Man hat eine Problemstelle und löst sie. Früher hat man nicht mit XML und sowas gearbeitet, zumindest nicht so umfangreich wie heute. HTML-Seiten waren nicht so umfangreich programmiert und Internetprogrammierung war vor 10 Jahren auch bei weitem keine so große Sache wie heute. Man hat sich früher auf ganz andere Sachen konzentriert. Heutzutage setzt man sich ein Ziel und wenn es dazu Bibliotheken gibt die einem das Leben gewaltig erleichtern - wieso nicht? Du benutzt doch auch nicht C und programmiert mithilfe des Präprozessors'ne Art von Objektorientierung, nur damit du es selber machst, oder? Du benutzt auch nicht Assembler, damit du auch ganz allein alles programmiert... Man abstrahiert sich immer weiter, so sollte vernünftige Programmierung aussehen. Modular, voneinander unabhängig.

Internet Scraping ist nunmal eine sehr eklige Aufgabe. HTML, der nicht wirklich valide ist, zu parsen und zu benutzen erfordert _sehr_ viel Aufwand. Also entweder man entfernt sich so weit von dem eigentlichen Problem, behandelt dieses Web Scraping selber (wovon man wahrscheinlich eh nicht soviel Ahnung hat wie von der eigenen Problemstellung), implementiert das unter Umständen unvollständig, so dass es nich richtig getestet werden kann... Oder man verwendet eine gut getestet Bibliothek. Für jede Problemstellung muss man abwägen, was man wo am besten macht. Wann ist es sinnvoller, eine Bibliothek zu verwenden, wann sind diese Probleme drumherum so klein, dass ich auch schnell ein Modul selber schreiben kann. Es gibt nunmal Gebiete, wo jemand besser programmiert.

Manche Leute sind wesentlich besser in Webprogrammierung, die schreiben dann ein Framwork für Leute, die's nur als Plattform für eine Applikation benutzen wollen. Viele Leute, die die "low-level"-Programmierung gut beherrschen, schreiben schreckliche Benutzeroberflächen, befassen sich nicht viel mit der Dokumentation an den Enduser und sowas. Probleme richtig aufzuteilen, so dass jeder das tut was er am besten kann... so muss programmierung sein, meiner Meinung nach. Früher wurde das auch schon gemacht - nur nicht in diesem Maße wie heute. Das Internet ist eine wunderschöne Plattform dafür.

Natürlich muss ich dir auch recht geben. Es gibt viele Leute, die eine Programmiersprache einfach nicht beherrschen und trotzdem Programme mit 300 Zeilen Code entwickeln, wo jede Funktion irgendwie anders aussieht, einen anderen Stil hat. Sowas spiegelt sich auch immer wieder... Denn jeder programmiert anders. Zusammenkopieren geht fast immer schief auf langer Sicht, sinnvolle Bibliotheken _richtig_ benutzen, im richtigen Umfang... ist oft eine sehr kluge Idee.
madfrog
User
Beiträge: 19
Registriert: Montag 19. Januar 2009, 01:56

Vermutlich nur ein nostalgischer Anfall. Du hast schon recht, wenn du sagst, daß es beim Programmieren natürlich nie verkehrt ist, auf Code zurückzugreifen, der erstens gut funktioniert und zweitens auch noch sehr ausgiebig getestet ist und eventuell auch ständig erweitert wird. So ist man auch in der Lage schnell zu respektablen Ergebnissen zu kommen. Nur büßt man damit auch viel Freude darin ein, ein Problem wirklich vollständig selber zu lösen. Auch sind die häutigen Laufzeitumgebungen komplexer als damals. Meine ersten Programmiererfahrungen habe ich in DOS gemacht und es war total In Demos zu programmieren. Da freute man sich dann alleine wenn man es schaffte den Interrupt 13 zu meistern (war doch Interrupt 13 oder? Schon so lange her.) Und das klicken des Monitors beim Umschalten des Grafikmodus war dann schon ein wahres Erfolgserlebnis. Dabei hatte man erstmal nur ein schwarzen Monitor vor sich. Linienzeichnen mal ganz zu schweigen. Und ja sowas mußte man dann in Assembler machen, wenn man einigen Wert auf Performance gelegt hat. Auch Bücher von Knuth oder Sedgewick habe ich damals verschlungen, doch das ist heutzutage wohl nicht mehr angesagt. Man steigt halt einfach viel höher ein und belastet sich nicht mehr mit dieser Art von Problemen.
rayo
User
Beiträge: 773
Registriert: Mittwoch 5. November 2003, 18:06
Wohnort: Schweiz
Kontaktdaten:

Hi

Also im embedded Bereich ist das halt noch eher so. Sehr hardwarenahe Programmierung und auch mal Assembler wenns wirklich schnell sein muss.

Ich habe in meiner Ausbildung das ganze Zeugs auch gelernt, von Prozessorarchitektur bis hin zu Assembler usw. Das setzt man heutzutage zwar nicht mehr direkt ein, jedoch hilft es einem, besseren Code zu schreiben, weil man weiss wie es darunter funktioniert. Sei es nun was die CPU schneller ausfuehren kann oder auch wie Fliesskommazahlen dargestellt werden usw.

Heutzutage kann man sich eher um sein Problem kuemmern, als sich um die Umgebung kuemmern zu muessen.

Gruss
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

madfrog hat geschrieben:Nur büßt man damit auch viel Freude darin ein, ein Problem wirklich vollständig selber zu lösen. Auch sind die häutigen Laufzeitumgebungen komplexer als damals. Meine ersten Programmiererfahrungen habe ich in DOS gemacht und es war total In Demos zu programmieren.
Aber du hast auch ein OS benutzt, also bist du auch schon von irgendeiner Abstraktion ausgegangen statt dich mit so spaßigen Problemen wie "wie bekomme ich Daten vom IDE-Controller" und "Wie kann ich die Daten auf einer Festplatte am besten organisieren". Natürlich, das kannst du auch heutzutage noch alles selbst machen jedoch ist das ein großer Aufwand und damit was du dann nach vielen Stunden schaffst entlockst du den meisten Programmierern nur ein müdes lächseln und den Kommentar "das hätte man mit Linux und OpenGL in einem zwanzigstel der Zeit geschafft". Ich für meinen Teil bin froh, dass ich viel von der Abstraktion als gegeben ansehen kann und mich damit nicht befassen muss weil es mich schlichtweg nicht sonderlich interessiert. Gerade dass es Libraries gibt ermöglicht es, dass ich Zeit habe mich mit den Sachen zu beschäftigen die mich interessieren.
madfrog hat geschrieben:Auch Bücher von Knuth oder Sedgewick habe ich damals verschlungen, doch das ist heutzutage wohl nicht mehr angesagt. Man steigt halt einfach viel höher ein und belastet sich nicht mehr mit dieser Art von Problemen.
Tim Peters meinte mal: "We read Knuth, so you don't have to".
__marcus__
User
Beiträge: 92
Registriert: Mittwoch 10. September 2008, 22:10
Wohnort: Hamburg

Guck doch mal z.B hier: http://ubuntuusers.de/inyoka/

1. Wenn man das alles selber schreiben würde, würde das zwangsläufig dazu führen, dass man mit einem schlechteren Gesamtprodukt früher zufrieden sein könnte und müsste.

2. Selbst Du wirst nicht behaupten, dass man so viele Einzelteile allein mit Copy+Paste zusammenfügen kann.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Die Entwickler von Inyoka haben aber ihre Finger zumindest bei Jinja, Pygments und Werkzeug im Spiel.
__marcus__
User
Beiträge: 92
Registriert: Mittwoch 10. September 2008, 22:10
Wohnort: Hamburg

Merkt man an der Werkzeug-Doku...
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

DasIch hat geschrieben:Die Entwickler von Inyoka haben aber ihre Finger zumindest bei Jinja, Pygments und Werkzeug im Spiel.
Uh und ich würde direkt sagen dass es andersrum ist :) Eigentlich sind da in allen angesprochenen Projekten große Schnittmengen wenn man sich die Entwickler ansieht. Zudem die Werkzeug-Doku wohl auf längere Sicht gesehen auf Sphinx migrieren wird, so wie Django das schon getan hat.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Leonidas hat geschrieben:
madfrog hat geschrieben:Auch Bücher von Knuth oder Sedgewick habe ich damals verschlungen, doch das ist heutzutage wohl nicht mehr angesagt. Man steigt halt einfach viel höher ein und belastet sich nicht mehr mit dieser Art von Problemen.
Tim Peters meinte mal: "We read Knuth, so you don't have to".
*g* den kannte ich noch nicht ;-)

@madfrog: Aber wo ist das Problem? Wenn es Dich interessiert z.B. coole Graphen-Algos selber zu implementieren kannst Du das doch tun! Wenn Du natürlich ein Problem lösen willst, was als Unterproblem einen Dijkstra-Algo benötigt, dann willst Du doch u.U. den gar nicht selber implementieren, sondern freust Dich darüber, dass es so was ggf. schon git! (Und bei ersterem freut man sich doch ggf. auch darüber, dass man Graphen wunderbar per GraphViz und DOT Language visualisieren kann ;-) )

Es nimmt einem ja keiner etwas weg - aber man muss bei einem Projekt idR eben nicht mehr bis in die 2., 3. oder nte Ebene unterhalb des eigentlichen Problems vorstoßen, da es dafür eben oftmals schon gute Libs gibt, die die dort fälligen Aufgaben für einen lösen.
madfrog
User
Beiträge: 19
Registriert: Montag 19. Januar 2009, 01:56

Danke für eure Antworten. Wie gesagt ist das nicht wertend gemeint. Es ist halt nur anders als früher. Man gibt generell mehr Kontrolle ab und baut eher die Schnittstellen zwischen den spezialisierten Modulen. Das hier paßt aber ins Bild: http://www.python-forum.de/post-123334.html#123334.

Das nächste Mal google ich erstmal :)
Antworten