Programmieren seit Dekaden

[mutetella]

Manche Dinge muss man sich einfach schönsaufen ...

[mutetella]

Habe auch letztens festgestellt dass ich knapp 10 Jahre dabei bin, ...

Ach, das waren noch Zeiten… kann mich noch gut daran erinnern, wie viel Überwindung es mich gekostet hat, von „ordentlichen“ Sprachen [...] zu diesem komischen „Python“ zu wechseln…

Ich bin definitiv zu früh geboren !
In dem Alter, als ihr bereits mit Python und anderen Sprachen vertraut wurdet, musste ich mit dem Fahrrad und 2 leeren 5.25" Disketten zum nächsten "EDV Fachgeschäft" radeln um irgend 'nen Treiber oder so zu besorgen. Und um mein Clipper (kostete viele Hundert Mark) um sowas ähnliches wie das Python `re`-Modul zu erweitern, musste ich mir das für ~70 Mark kaufen.
Zugang zu einer gleichgesinnten Community gab's nicht so ohne weiteres. Also war man mit seiner 1000 Seiten schweren Dokumentation, die überhaupt nicht mit sowas wie der Python Dokumentation vergleichbar ist, auf sich gestellt.

Die paar wenigen Interessierten kamen eigentlich selten über das Stadium hinaus, durch Karstadt zu laufen und

Code: Alles auswählen

10 print "Sabine ist doof"
20 goto 10

in jeden C64 zu tippen.

Sorry..., aber das musste Euch der Opa jetzt einfach mal sagen!

mutetella

[kbr]

Ich bin definitiv zu früh geboren !

Keineswegs: Du hast eine sehr spannende Zeit erlebt.

[BlackJack]

Ich möchte kbr da zustimmen. CBM BASIC V2 ist zwar eine furchtbare Sprache, aber ohne sie wäre ich wahrscheinlich nicht motiviert gewesen Assembler auf dem C64 zu lernen — und damit eine Menge darüber wie so ein Rechner auf einer sehr hardwarenahen Ebene funktioniert.

Wir „Opas” haben IMHO eine Entwicklung hin zu den modernen Programmiersprachen und Konzepten *mitgemacht* die heutigen Einsteigern fehlt und die sie sozusagen im Zeitraffer nachvollziehen müssen.

[lunar]

@BlackJack Nachvollziehen müssen? Wirklich? Reichen die modernen Sprachen nicht? Oder spricht daraus nur der Neid auf die Spätgeborenen, die sich nicht mehr mit Assembler herumplagen müssen?

@mutetella Ich freue mich schon auf die Zeiten in 25 Jahren, in denen ich das dann zu jungen Nachwuchs-Programmierern sagen kann

[mutetella]

@kbr, BlackJack:
Ihr habt sicherlich Recht damit, dass man sich damals, wollte man etwas tiefer in die Materie einsteigen, zwangsläufig mit grundlegenden Techniken, Konzepten etceterapepe auseinandersetzen musste. Ich bin mir nur nicht sicher, ob das heute noch in dem Maße relevant, besser gesagt, notwendig ist.

Wenn ich halt sehe, mit welcher Leichtigkeit und Geschwindigkeit junge Leute heute den Umgang mit Programmiersprachen aufsaugen, dann könnte ich schon wehmütig werden. Ist es nicht so, dass z. B. dieses Forum und unzählige andere Community-Zugänge, kostenlose hochwertige Informationen an jeder Ecke, günstigste Hardware und so weiter Dinge sind, die in den 80ern/90ern in umgekehrter Form eher Hürden darstellten?
Ich möchte damit nicht sagen, dass die Jungs (wo sind eigentlich die programmierenden Frauen??), die ich z. B. während der letzten beiden PyCon's erleben durfte, heutzutage weniger ehrgeizig, begabt und kreativ sein müssten. Aber sie haben es einfacher und kommen durch heutige Selbstverständlichkeiten wesentlich schneller voran.

Ich freue mich schon auf die Zeiten in 25 Jahren, in denen ich das dann zu jungen Nachwuchs-Programmierern sagen kann

So gesehen lebt jeder in einer unglaublich spannenden Zeit! Allein die Vorstellung kann einem den Atem nehmen...

mutetella

[kbr]

Ist es nicht so, dass z. B. dieses Forum und unzählige andere Community-Zugänge, kostenlose hochwertige Informationen an jeder Ecke, günstigste Hardware und so weiter Dinge sind, die in den 80ern/90ern in umgekehrter Form eher Hürden darstellten?

Definitv. Verglichen mit früher ist der Zugang zu Informationen heute sehr viel leichter.

Ich möchte damit nicht sagen, dass die Jungs (wo sind eigentlich die programmierenden Frauen??), die ich z. B. während der letzten beiden PyCon's erleben durfte, heutzutage weniger ehrgeizig, begabt und kreativ sein müssten. Aber sie haben es einfacher und kommen durch heutige Selbstverständlichkeiten wesentlich schneller voran.

Das aber gilt heute für uns alle; schön, dass Du auch auf der pyCon warst.

[BlackJack]

@lunar: Ich denke wenn sie gute Programmierer werden wollen, werden sie es nachvollziehen *müssen*. Dabei meine ich nicht unbedingt das sie Assembler schreiben müssen, sondern sich irgendwie das Wissen aneignen müssen, welches man dabei erlangt. Ich finde schon, dass das hilfreich ist. Zum Beispiel Speicherlayout und Bitmanipulationen wenn man mit Dateiformaten oder Kommunikationsprotokollen zu tun hat. Oder wenn man sich ein Laufzeitverhalten nicht so ganz erklären kann und deshalb das `dis`-Modul her nimmt. Oder halt auch bei anderen Sprachen in denen es einen Assembler-ähnlichen Bytecode gibt. Dann gibt es auf höherer Ebene die ganzen „best practices” deren Wert man IMHO besser einschätzen kann, wenn man selbst mal mit viel unstrukturiertem Spaghetticode in einem einzigen Namensraum zu tun gehabt hat.

Neidisch bin ich auf die Spätgeborenen überhaupt nicht. Ich habe mich auch nie wirklich mit Assembler *herumgeplagt*, im Gegenteil — das macht mir auch heute noch Spass. Genau so wie C, was ich als so etwas wie einen portablen Makro-Assembler sehe.

@mutetella: Man muss heute nicht mehr den Rechner, die Hardware und das Betriebssystem auf einer Ebene kennen wie das damals mit dem C64 „üblich” war. Dazu sind die Systeme auch zu komplex um noch mit jedem einzelnen Bit in den I/O-Registern per Du zu sein. Aber ich denke das grundsätzliche Verständnis wie ein Rechner in der von Neumann-Architektur funktioniert, sollte ein guter Programmierer haben. Wirklich nur auf einer ganz abstrakten Ebene Problemlösungen zu formulieren ohne sich darum zu kümmern wie das auf dem darunter liegenden Rechner abgebildet wird, fällt einem früher oder später in Form von Laufzeiten oder Speicherverbrauch auf die Füsse.

Das Internet macht einiges einfacher und günstiger, aber zu C64-Zeiten gab es doch Zeitschriften und Bücher (und für letztere öffentliche Bibliotheken), und die „Szene”, wo man sich austauschen konnte. So ab Mitte der 80er kamen BBSen (falls das der richtige Plural ist) dazu, mit viel kostenloser Information zum Thema Programmieren, Formaten, Protokollen, und so weiter. Wer da mal in Nostalgie schwelgen möchte: http://textfiles.com/

[Leonidas]

@lunar: Ich denke wenn sie gute Programmierer werden wollen, werden sie es nachvollziehen *müssen*. Dabei meine ich nicht unbedingt das sie Assembler schreiben müssen, sondern sich irgendwie das Wissen aneignen müssen, welches man dabei erlangt. Ich finde schon, dass das hilfreich ist. Zum Beispiel Speicherlayout und Bitmanipulationen wenn man mit Dateiformaten oder Kommunikationsprotokollen zu tun hat. Oder wenn man sich ein Laufzeitverhalten nicht so ganz erklären kann und deshalb das `dis`-Modul her nimmt. Oder halt auch bei anderen Sprachen in denen es einen Assembler-ähnlichen Bytecode gibt. Dann gibt es auf höherer Ebene die ganzen „best practices” deren Wert man IMHO besser einschätzen kann, wenn man selbst mal mit viel unstrukturiertem Spaghetticode in einem einzigen Namensraum zu tun gehabt hat.

Dem würde ich (mit Einschränkungen) zustimmen. Obwohl ich im wesentlichen kein Assembler programmiere, hat mir die Auseinandersetzung mit Assembler durchaus auch was gebracht, etwa habe ich dort zum ersten mal den Sinn von Pointern in C richtig verstanden.

Die Einschränkung ist, "sollte" jedoch nicht "muss". Ich kann mir durchaus auch vorstellen dass es gute bis sehr gute Programmierer gibt, die C nie angefasst haben und sich mit der low-level Welt nie auseinandergesetzt haben, weil sie einfach auf anderen Abstraktionsebenen unterwegs sind. Ich lande ständig bei der ungefähren Abstraktionsebene von C, weil ich den Bereich recht spannend finde, aber andere können durchaus andere Sachen wichtiger finden.

Ich habe übrigens das Thema abgetrennt, weil ich es ziemlich spannend finde. Wie wärs wenn jeder so etwas aus dem Nähkästchen plaudert, was so seine Beobachtungen zu Programmierung waren, so in etwa wie ich das im Blogpost gemacht habe? Muss ja nicht über Python sein, auch in anderen Bereichen gab es in den letzten Jahren spannende Sachen.

@mutetella: Ich glaube beim abtrennen hab ich einen Beitrag von dir verloren. Das tut mir Leid, war keine Absicht

[mutetella]

Ich glaube beim abtrennen hab ich einen Beitrag von dir verloren.

Kein Problem. Passend zum Thema kann ich da nur sagen: In meinem Alter ist man schon froh, wenn es nur ein Beitrag war, der verloren ging.

Ich denke wenn sie gute Programmierer werden wollen, werden sie es nachvollziehen *müssen*. [...]

Das ist mir zu pauschal. Ein guter Programmierer muss IMHO nicht nur guten Code schreiben. Genauso wenig wie ein guter Musiker nur richtig spielen sollte. Für mich ist auch der ein guter Programmierer, der ein gut bedienbares UI bzw. sinniges API umsetzen kann.
Ich zähle mich selbst nicht zu den guten Programmierern und werde es wohl auch nicht mehr werden. Deshalb kann ich auch meine Meinung nicht fachlich unterfüttern. Aber ich will nicht glauben, dass nur der, der sich von "unten nach oben" mit der Materie auseinandersetzt, ein guter Programmierer werden kann.

Wenn ich so innerhalb der OS-Szene die vielen teils sehr jungen Menschen aus Indien, Lateinamerika, Asien aber eben auch die tollen Leute hier im Forum sehe habe ich immer wieder den Eindruck, dass diese Jungs sich um Althergebrachtes reichlich wenig scheren und vielleicht gerade deshalb den Umgang mit Programmiersprachen und allem, was damit einhergeht, in einer Art und Weise verinnerlicht haben, wie es einem "alten Hasen" vielleicht nicht mehr möglich sein wird.
Und ich kann mir nicht helfen: Diese ungezwungene, blasphemische Herangehensweise ist faszinierend und ich glaube, wir werden in den kommenden Jahren unglaubliche Software erleben, geschrieben von heute vielleicht 13- bis 16-jährigen. Ob es sich dabei um gute Entwickler handelt wird wohl an neuen Kriterien festgemacht werden müssen.

mutetella

[BlackJack]

@mutetella: Eine gute API zu entwerfen würde ich zu gutem Code schreiben dazu zählen. Und die Richtung wollte ich nicht vorgeben. Man muss sich nicht von unten nach oben durch die „Schichten” arbeiten, man kann auch gerne mit einer Hochsprache anfangen und sich dann Richtung Hardware vorarbeiten. Hauptsache man bekommt ein Verständnis davon wie ein Rechner im Kern arbeitet und wie zur Hochsprache hin dazwischen Abstraktionsschichten gezogen wurden.

Was meinst Du mit Althergebrachtem? Du weisst wie alt Objektorientierung ist? Und dynamische Programmiersprachen sind auch keine Erfindung von gestern. Ich würde eher sagen das sind Wiederentdeckungen, teilweise auch deswegen salonfähig weil die Rechner heute so leistungsstark sind, dass es bei vielen Anwendungen nicht mehr so sehr ins Gewicht fällt, dass es keine statisch kompilierten Binärprogramme sind, die direkt vom Prozessor ausgeführt werden. Man hat keinen nennenswerten Laufzeitnachteil mehr, aber dafür den Vorteil eines kürzeren Entwicklungszylus.

Auch die Jungen werden zum beherrschen einer Programmiersprache die üblichen 10 Jahre brauchen. Siehe Norvig's Essay was erst kürzlich von Leonidas und von mir mal wieder verlinkt wurde. Den einzigen Vorteil den ich bei denen sehe ist dass sie noch von Paradigmen unbelastet sind, und es vielleicht tatsächlich schaffen etwas komplexeres in Haskell zu programmieren. Das habe ich aufgegeben.

Die neuen Kriterien sehe ich nicht. Der Massstab wird weiterhin bleiben ob jemand es schafft verständlichen, wart-, und erweiterbaren Quelltext zu schreiben. Ich sehe nicht was sich daran ändern sollte. Heute hat man mehr Möglichkeiten guten Quelltext zu lesen und davon zu lernen und mit anderen Programmierern zusammen zu arbeiten als früher. Das gilt aber nicht nur für die Jungen, sondern auch für die alten Hasen.

[lunar]

@BlackJack Ich glaube nicht, dass ich jetzt zum Beherrschen einer neuen Sprache zehn Jahre brauche… meine praktische Erfahrung spricht gänzlich gegen diese These, die vielleicht allenfalls für die allererste Sprache gilt, oder für eine wirklich ganz und gar fremde (e.g. eine logische nach jahrelanger imperativer Programmierung).

Ich halte es auch nicht für notwendig, sich durch alle „Schichten“ zu arbeiten, um zu einem guten Programmierer zu werden. Wenn man sich auf allen Schichten bewegt, wird man vielmehr allenfalls zu einem mittelmäßigen Universalprogrammierer. Implizit widersprichst Du Deiner These selbst, wenn Du eingestehst, dass Du mit Haskell nicht warm wirst. Du bist mithin zwar gut vertraut mit den tieferen Schichten, doch die hochabstrakte Ebene von Haskell bleibt Dir verschlossen.

Du bist deshalb selbstverständlich kein schlechter Programmierer… [1]. Ebenso aber ist derjenige Haskell-Programmierer kein schlechter Programmierer, der komplizierteste Haskell-Konstrukte aus dem Ärmel schütteln kann und besser Kategorientheorie als Englisch spricht (man höre und staune, diese erlesene Art Programmierer gibt es tatsächlich), aber Reisaus nimmt, wenn er die Worte Interrupt oder Register vernimmt, und C nur für den dritten Buchstaben im Alphabet hält.

Es kann eben auch gute Programmierer geben, die keine Ahnung von Hardware haben, und im Bezug auf das Verständnis von Hardware bei Trennung von Arbeitsspeicher, Prozessor und Festplatte stehen geblieben sind. Diese Programmierer bewegen sich halt in einem ganz anderen Umfeld (meist natürlich eher im akademischen). Das macht sie aber nicht schlechter… warum auch? Ich sehe nicht, warum ein Haskell- oder Prolog-Programmierer, oder gar jemand, der formale Beweise in Coq programmiert, Ahnung von Registern, Interrupts, etc. haben sollte, oder sich unbedingt über Speicherverbrauch und Laufzeit der eigenen Programme Gedanken machen müsste. In stark deklarativen Umgebungen (worunter die meisten Theorembeweiser fallen) ist das ohnehin wenig bis gar nicht möglich…

Man erkennt einen guten Programmierer meines Erachtens nicht an den Abstraktionsschichten, auf denen er sich bewegt, noch an den Sprachen, die er spricht, oder den Technologien, die er beherrscht, sondern an der Bereitschaft, ein Problem nach besten Wissen und Gewissen gut, elegant und lesbar zu lösen, gleich in welcher Sprache oder auf welcher Abstraktionsebene sich dieses Problem stellt.

PS: Die Bemerkung über erlesene Haskell-Programmierer wollte ich eigentlich mit einem hübschen Vergleich schmücken, der Art, „sie sind in etwa so häufig wie <insert seltenes Tier here>“. Um das seltene Tier zu finden, habe ich auf Wikipedia die Rote Liste gesucht… und dabei festgestellt, dass allein die Liste der kritisch bedrohten Tiere fast 2000(!) Spezies umfasst

Lesson Learned: Wir haben eigentlich ganz andere und viel wichtigere Probleme als diese Diskussion…

[mutetella]

Die neuen Kriterien sehe ich nicht. Der Massstab wird weiterhin bleiben ob jemand es schafft verständlichen, wart-, und erweiterbaren Quelltext zu schreiben.

Für Dich als Programmierer ist das ein Massstab, ja. Nicht aber für die in den letzten ~ 30 Jahren rasant gewachsene Zahl an Nutzern. Und die setzen auch Massstäbe, an die sich ein (guter) Programmierer halten muss. Zu präcommodorschen Zeiten lag die Zahl der Softwarenutzer und -entwickler wahrscheinlich um die 60:40. Und Nutzerfreundlichkeit war sicher kein Kriterium, das ein Softwareentwickler auf seinem Radar hatte.
Das meinte ich mit neuen Kriterien. Die riesige Masse an Nutzern mit ihren teils sehr kurzlebigen und beliebigen Anforderungen an die Software.

mutetella

[mutetella]

Lesson Learned: Wir haben eigentlich ganz andere und viel wichtigere Probleme als diese Diskussion…

Sollte diese Diskussion dazu beitragen, dass das, was jemand tut besser wird, so ist sie durchaus wichtig. Alles, was wir gut machen, wird gutes hervorbringen.

Ein zugegebenermaßen abstruses Beispiel, mir fällt leider nix anderes ein: Sollte ein Politiker, der ein wichtiges Artenschutzprogramm voranbringen möchte, einen Herzinfarkt erleiden und der Rettungswagen kommt rechtzeitig, weil gut programmierte Handysoftware, Netztechnik und so weiter dazu beigetragen hat... Weißt Du, was ich meine?

Ich glaube, es gibt nur sehr wenig, das sich, gemessen an seiner Bedeutung, über anderes stellen könnte.

mutetella

P.S. Ich muss das glauben, sonst werd' ich mit meinem Kalender nie fertig...

[snafu]

@mutella: Du musst das aber noch weiter ausführen: Wenn sie deine fehlerfrei laufende Kalender-App nicht genutzt hätten (die es bald bestimmt auch für Smartphones gibt), dann hätten sie gedacht, es wäre Wochenende und sie hätten frei. Dann wären sie an dem Tag nicht zur Arbeit gekommen und niemand hätte den armen Politiker gerettet...

[Kensen468]

Da wir uns grade in Nostalgie wälzen und ich keinen Vorstell-Thread für Neulinge gefunden habe, verbinde ich das doch gleich mal

Selbst hatte ich mit etwa 8 Jahren damit begonnen, mich mit dem Programmieren auseinanderzusetzen, damals noch mit Pascal. Das war Ende 80er/Anfang 90er. Später kamen dann noch Basic, Visual Basic und C++, seit neustem nun Python. Auch ich habe mich noch mit Assemblern herumschlagen dürfen, grösstenteils hobbymässig, teilweise aber auch wirklich noch, um meine Programme zum Laufen zu bringen.

Ich halte es auch nicht für notwendig, sich durch alle „Schichten“ zu arbeiten, um zu einem guten Programmierer zu werden.

Dem kann ich zustimmen. Man kann guten Code schreiben, ohne die Details seiner Verarbeitung zu kennen. Für mich persönlich hatte es aber immer seinen Reiz, alles bis zu seinen Ursprüngen zurückzuverfolgen. Als ich begonnen habe, brauchte man Assembler kaum mehr, ich hab's mehr aus Freude an der Sache gelernt. Leider aber ist in den letzten rund 20 Jahren viel Wissen verloren gegangen, was ich sehr bedaure.

Ich denke, die Qualität eines Programmes entscheidet sich vor allem im Rückblick von seiner Verwendung her. Viele Programme müssen ja von Leuten bedient werden, die nicht die geringste Ahnung vom Code dahinter haben. Dementsprechend muss es für den Endnutzer klar gegliedert und einfach zu bedienen sein (wohlgemerkt: die meisten Fehler diesbezüglich werden schon lange vor Beginn der Programmierung begangen...). Es muss zu den bereits vorhandenen Applikationen passen, seine Aufgabe bei minimaler Rechenleistung möglichst elegant lösen und dabei trotzdem noch einfach zu erweitern sein.

Die riesige Masse an Nutzern mit ihren teils sehr kurzlebigen und beliebigen Anforderungen an die Software.

Das ist einfach der Zeitgeist... Ich kann mich noch gut erinnern, wie der erste Fernseher meiner Eltern, so alt wie ich selbst, über 20 Jahre durchgehalten hat. Mittlerweile ist es aber so, dass man ja alle zwei Jahre spätestens wieder ein neues Gerät braucht, um auf dem neusten Stand zu sein. Mit Applikationen ist das kaum anders.
Einerseits ist das Problem mal, dass diese ja oftmals die genannten Geräte bedienen helfen und zweitens übertragen die Kunden das "Wegwerf"-Denken halt auch auf die digitalen Produkte. Dass letztere dabei der grossen Masse zu Verfügung stehen, ist aber auch wieder eine Eigenheit unserer Zeit (das ist in keiner Weise wertend gemeint!).

[BlackJack]

@lunar: Es kommt natürlich darauf an wie verschieden eine neue Sprache und deren idiomatische Verwendung von den bisher gelernten ist. Vielleicht bin ich auch ein schlechter(er) Programmierer, aber ich denke für Python habe ich schon so an die 5 Jahre gebraucht bis ich das Gefühl hatte nicht mehr viel neues zu lernen beziehungsweise das Neues nur noch durch die Weiterentwicklung der Sprache hinzu kommt. Trotz der anderen Sprachen, die ich bis dahin schon halbwegs drauf hatte.

Man muss sich nicht auf allen Schichten bewegen, also ständig hochabstrakt *und* auf Gerätetreiber-Niveau arbeiten, aber IMHO muss man ein gewisses Verständnis für das Gesamtbild haben. Denn die abstrakteste Sprache läuft letztendlich ja doch auf der „primitiven” Hardware.

Wenn ein Programmierer das Laufzeitverhalten oder den Speicherverbrauch seines Programms nicht erklären kann, also im Ernstfall nicht sagen kann, dass es normal ist, sprich einfach nicht besser geht, oder aber weiss wie er das Programm umformulieren muss, damit sich das Verhalten verbessert, dann gibt es IMHO entweder ein Problem mit dem Programmierer oder der verwendeten Sprache.

Mir bleibt Haskell auch nicht gänzlich verschlossen, was mir dabei nicht klar ist, ist eben der Sprung zur Umgebung. Irgendwie kollidieren dort für mich die reine funktionale Lehre von Haskell und das sehr zustandsbehaftete Restsystem. Da wirkt Haskell für mich wie ein Fremdkörper. Und für die praktische Anwendung von Haskell habe ich auch noch nicht verstanden wie man elegant mit Fehlern und Ausnahmesituationen umgeht. Was ich bisher gesehen habe war immer eleganter Code der praktischerweise davon ausgegangen ist, dass es keine Fehler (Fehleingaben, kaputte Eingabedaten) gibt, oder der voll von Funktionen war die „Maybe”s durch die ganze Aufrufhierarchie gezogen haben, also jene Art von Fehlercode den man überall explizit behandeln muss und den man bei modernen imperativen und objektorientierten Sprachen $GOTT sei Dank durch Ausnahmebehandlung abgelöst hat.

Übrigens sind mittelmässig bis gute Universalprogrammierer IMHO bessere Programmierer als solche, welche die kompliziertesten Haskell-Konstrukte aus dem Ärmel schütteln. Denn deren Quelltexte sind für die meisten Programmierer nicht lesbar und verständlich.

[snafu]

Wenn ein Programmierer das Laufzeitverhalten oder den Speicherverbrauch seines Programms nicht erklären kann, also im Ernstfall nicht sagen kann, dass es normal ist, sprich einfach nicht besser geht, oder aber weiss wie er das Programm umformulieren muss, damit sich das Verhalten verbessert, dann gibt es IMHO entweder ein Problem mit dem Programmierer oder der verwendeten Sprache.

Ist ja alles richtig. Auch sollte man zum Beispiel wissen, dass Zugriffe auf Daten aus dem Arbeitsspeicher in der Regel wesentlich schneller sind als Festplattenzugriffe. Generell können IO-bezogene Kenntnisse beim Programmieren nicht schaden. Das alles sind aber IMHO reine *Konzepte*. Man muss dafür nicht die darunterliegende Hardware genauer kennen.

[kbr]

Wenn ein Programmierer das Laufzeitverhalten oder den Speicherverbrauch seines Programms nicht erklären kann, also im Ernstfall nicht sagen kann, dass es normal ist, sprich einfach nicht besser geht, oder aber weiss wie er das Programm umformulieren muss, damit sich das Verhalten verbessert, dann gibt es IMHO entweder ein Problem mit dem Programmierer oder der verwendeten Sprache.

Das Problem würde ich eher beim Programmierer verorten als Zeichen mangelnder Kenntnis von Algorithmen. Und damit befinden wir weniger auf hardwarenaher Ebene als vielmehr am Schreibtisch mit Bleistift und Papier (und großem Radiergummi). Allerdings finde auch ich, dass ein grundlegendes Verständnis der verwendeten Hardware vorhanden sein sollte - ob dies bis auf Registerebene heruntergehen muss, halte ich für fragwürdig; es schadet aber auch nicht.
Um im Bild zu bleiben ist die Sprache ist letztendlich "nur" das Werkzeug zwischen Papier und Hardware. Und wie jeder gute Handwerker seinen Werkzeugkasten kennen sollte, sollte ein guter Programmierer eine Vielzahl von Programmiersprachen kennen, um deren Eignung für bestimmt Zwecke beurteilen zu können.
Das Interessante an Python ist IMHO, dass, zumindest bei mir, der Bedarf an anderen Sprachen praktisch gegen Null tendiert. Mit C im Rücken braucht man sich auch keine Sorgen darüber zu machen, bei möglichen laufzeitkritischen oder systemnahen Problemen gegen die Wand zu laufen.
Aber damit bin ich praktisch bei Deiner Aussage wieder angekommen mit dem Unterschied, dass die Verwendung der "falschen" Sprache auch ein Fehler des Programmierers ist, jedenfalls solange dieser über deren Wahl zu entscheiden hat.

[DasIch]

Wenn ein Programmierer das Laufzeitverhalten oder den Speicherverbrauch seines Programms nicht erklären kann, also im Ernstfall nicht sagen kann, dass es normal ist, sprich einfach nicht besser geht, oder aber weiss wie er das Programm umformulieren muss, damit sich das Verhalten verbessert, dann gibt es IMHO entweder ein Problem mit dem Programmierer oder der verwendeten Sprache.

Das Problem würde ich eher beim Programmierer verorten als Zeichen mangelnder Kenntnis von Algorithmen. Und damit befinden wir weniger auf hardwarenaher Ebene als vielmehr am Schreibtisch mit Bleistift und Papier (und großem Radiergummi).

Es sei den du benutzt eine Sprache die keine strikte Ausführung hat wie z.b. Haskell. Die Geschwindigkeit oder den Speicherverbrauch eines Haskell Programms auch nur abzuschätzen, dürfte für Leute die nicht an einer Haskell Implementation arbeiten nahezu unmöglich sein. Ob man da Ahnung von der Hardware oder den Algorithmen hat und wie viel ist da vollkommen irrelevant.