Lässt sich Reference Counting nicht entfernen, wenn sich der Zeitpunkt der Speicherallokation und -freigabe zur Compile-Zeit berechnen lässt? Es scheint, als würde der Verfasser des ursprünglichen Hacker-News-Kommentars das Problem der Speicherwiederverwendung nicht verstehen.
Wie in diesem Artikel behauptet wird, ist die Fähigkeit zur „Dokumentation“ wirklich wichtig.
Sie dient nicht nur dazu, die eigenen Stärken hervorzuheben und Erfolge geltend zu machen, sondern macht die Arbeit auch angenehmer und hilft dabei, anderen Anweisungen zu geben.
Man muss nicht von Anfang an großartige Materialien oder Dokumente erstellen. Wichtig ist, sich die Gewohnheit anzueignen, Dinge zu ordnen und zu dokumentieren, auch wenn es einfach ist.
Ich weiß das auch theoretisch, setze es aber nicht gut in die Praxis um ... Das ist wirklich ein sehr schwieriges Thema.
Ich kenne vielleicht nicht einmal die tieferen Grundlagen, aber ich habe gesehen, was für wirklich absurde und völlig unvorstellbare Ergebnisse entstehen, wenn man die Grundlagen nicht kennt.
Zum Beispiel eine Implementierung, die alle Datensätze aus der DB in den Speicher lädt und dann im Speicher durchsucht.
Solange es nur wenige Datensätze gibt, funktioniert es gut, aber wenn es viele werden, läuft der Speicher voll.
So wird so etwas geschrieben, weil man überhaupt nicht versteht, wie sich Speicher und DB unterscheiden.
Das ist nur ein Beispiel, und jedes Mal wird es in eine Richtung implementiert, die man sich wirklich nie hätte vorstellen können.
Ein normaler(?) Programmierer kann sich so etwas wirklich nicht ausmalen.
Ich stimme diesem Beitrag ebenfalls zu.
Ich halte es für nützlich, Probleme über abstrahierte Zustandswerte zu definieren, um Probleme zu entdecken, und versuche, Tools für ein klares Zustandsmanagement zu entwickeln, die Zustände visuell und explizit darstellen, etwa durch Diagramme, Unreal Blueprint oder Workflows.
Dann sollte ich mir wohl zuerst die Sprache ansehen.
Wie auch immer: Die praktische Arbeit im Software Engineering wird sich stark verändern. Code-Maschinen werden an Wettbewerbsfähigkeit verlieren, aber ich wette darauf, dass Ingenieure überleben werden, die tatsächlich in der Lage sind, Produkte End-to-End zu entwickeln.
Ich habe während meiner Arbeit in der Entwicklung einmal für einige Jahre kurz im Planungsbereich gearbeitet, und die Botschaft im Text, dass man etwas „verkaufen“ muss, spricht mich sehr an.
Egal, wie sorgfältig ein Produkt vorbereitet und geplant ist: Wenn man es den Kolleginnen und Kollegen in seinem Umfeld nicht überzeugend vermitteln und verkaufen kann, erhält man keine Unterstützung,
und am Ende kann das Projekt nicht reibungslos vorankommen.
Wenn man eine Idee hat, habe ich daraus die Lehre gezogen, dass es ebenfalls unverzichtbar ist, sie den Menschen um einen herum wirksam zu vermitteln und sich so Unterstützung zu sichern.
Lässt sich Reference Counting nicht entfernen, wenn sich der Zeitpunkt der Speicherallokation und -freigabe zur Compile-Zeit berechnen lässt? Es scheint, als würde der Verfasser des ursprünglichen Hacker-News-Kommentars das Problem der Speicherwiederverwendung nicht verstehen.
Jetzt, da generative KI Code schreiben kann, frage ich mich, ob wir überhaupt noch einen Garbage Collector brauchen.
> Das ist vielsagend ...
Ach, das werde ich später korrigieren.
Heißt das, dass
<selectlist>dann nicht mehr nötig sein wird?Show GN: Webspiel für Charakter-Setup-Battles/Rankings
Eine andere Sache: Im Slack-Bot wird das
<select>im Titel offenbar nicht angezeigt, haha.Als ich es gestern gesehen habe, wusste ich nicht, dass es von Microsoft ist, wow. Das muss ich ausprobieren.
Schade für die Blogger, die durch das Beobachten neuer Commits neue Funktionen vorhergesagt haben.
Kann ich nachvollziehen..!
Wie in diesem Artikel behauptet wird, ist die Fähigkeit zur „Dokumentation“ wirklich wichtig.
Sie dient nicht nur dazu, die eigenen Stärken hervorzuheben und Erfolge geltend zu machen, sondern macht die Arbeit auch angenehmer und hilft dabei, anderen Anweisungen zu geben.
Man muss nicht von Anfang an großartige Materialien oder Dokumente erstellen. Wichtig ist, sich die Gewohnheit anzueignen, Dinge zu ordnen und zu dokumentieren, auch wenn es einfach ist.
Ich weiß das auch theoretisch, setze es aber nicht gut in die Praxis um ... Das ist wirklich ein sehr schwieriges Thema.
Ich kenne vielleicht nicht einmal die tieferen Grundlagen, aber ich habe gesehen, was für wirklich absurde und völlig unvorstellbare Ergebnisse entstehen, wenn man die Grundlagen nicht kennt.
Zum Beispiel eine Implementierung, die alle Datensätze aus der DB in den Speicher lädt und dann im Speicher durchsucht.
Solange es nur wenige Datensätze gibt, funktioniert es gut, aber wenn es viele werden, läuft der Speicher voll.
So wird so etwas geschrieben, weil man überhaupt nicht versteht, wie sich Speicher und DB unterscheiden.
Das ist nur ein Beispiel, und jedes Mal wird es in eine Richtung implementiert, die man sich wirklich nie hätte vorstellen können.
Ein normaler(?) Programmierer kann sich so etwas wirklich nicht ausmalen.
https://de.news.hada.io/topic?id=4138
Es gibt auch einen Kandidaten namens Coolify.
Ich stimme diesem Beitrag ebenfalls zu.
Ich halte es für nützlich, Probleme über abstrahierte Zustandswerte zu definieren, um Probleme zu entdecken, und versuche, Tools für ein klares Zustandsmanagement zu entwickeln, die Zustände visuell und explizit darstellen, etwa durch Diagramme, Unreal Blueprint oder Workflows.
Dann sollte ich mir wohl zuerst die Sprache ansehen.
Das ist ein Text, der mich an einen Kurs in Berechenbarkeitstheorie erinnert! Ich empfehle allen, die programmieren, sich damit zu beschäftigen.
Wirklich großartig, oder? Dass es sogar so etwas als Open Source gibt, haha.
Schlechter ist besser!
Wie auch immer: Die praktische Arbeit im Software Engineering wird sich stark verändern. Code-Maschinen werden an Wettbewerbsfähigkeit verlieren, aber ich wette darauf, dass Ingenieure überleben werden, die tatsächlich in der Lage sind, Produkte End-to-End zu entwickeln.
Ich denke auch, dass OpenAPI Function Calling nicht besser wäre. Das noch einmal mit dem MCP-Protokoll neu aufzubauen, ist nämlich ebenfalls Aufwand.
Ich habe während meiner Arbeit in der Entwicklung einmal für einige Jahre kurz im Planungsbereich gearbeitet, und die Botschaft im Text, dass man etwas „verkaufen“ muss, spricht mich sehr an.
Egal, wie sorgfältig ein Produkt vorbereitet und geplant ist: Wenn man es den Kolleginnen und Kollegen in seinem Umfeld nicht überzeugend vermitteln und verkaufen kann, erhält man keine Unterstützung,
und am Ende kann das Projekt nicht reibungslos vorankommen.
Wenn man eine Idee hat, habe ich daraus die Lehre gezogen, dass es ebenfalls unverzichtbar ist, sie den Menschen um einen herum wirksam zu vermitteln und sich so Unterstützung zu sichern.
Schade, dass in einer Zeit, in der sogar Docker Desktop Kubernetes nutzt, nur Docker Swarm unterstützt wird.