Verleitet C++ zum komplizierteren denken?
-
u_ser-l schrieb:
mag sein. Wenn man alle selten vorkommenden Situationen nicht mehr als Problem auffaßt, vereinfacht sich manches. Auf Kosten der Stabilität und Vorhersagbarkeit.
Allgemeinplätze.
u_ser-l schrieb:
Ja, das Konzept, von einer echten OOP zu sprechen, obwohl das Laufzeitsystem von sich aus nicht einmal eine generelle Buchführung über die Objekte kennt, dehnt einige Begriffe der objektorientierten Denkweise bedenklich weit aus.
Schon wieder.
Alles, was Du nicht verstehst, ist keine ECHTE OOP. Naja, wenigstens hab ich Dir den Zahn mit der OBJEKTPROGRAMMIERUNG ziehen können. Aber die Diskussionsweise ist gleich. Nun baust Du Dir deinen eigenen Begriff ECHTE OOP (vormals OBJEKTPROGRAMMIERUNG) und schüttest willkürlich Merkmale hinein und begründest mit deiner Privatsprache wasauchimmer Du begründen magst.
Ein besseres Vorgehen wäre, daß Du Probleme findest, die sich mit einer Sprache prinzipiell nur sehr schlecht modellieren lassen. Ein Ansatzpunkte wär zum Beispiel fehlende mehrfache Erblichkeit.u_ser-l schrieb:
Nein, da hat jemand das Konzept RAII noch nicht einmal im Ansatz verstanden.
die durchsichtige Strategie "mir fällt kein gutes Gegenargument ein, da werfe ich dem Diskussionsteilnehmer einfach Unkenntnis vor" ist etwa so prickelnd wie ein Karamelbonbon im Rinnstein acht Wochen nach Ende des Kölner Karnevals.
Naja, aber er könnte recht haben.
u_ser-l schrieb:
Es ist kein C oder Java, bei dem man ständig von Hand Resourcen freigeben muß! Ums Abräumen der Objekte kümmert sich der Compiler.
jetzt muß ich aber mal herzhaft lachen. Wozu brauchst du denn in deinem Codebeispiel im K.tor und D.tor new und delete, wenn der Compiler das doch von selbst macht ?
Er hat recht. Aufrufen des Destruktors ist was ganz anderes als AUfrufen von delete.
-
volkard schrieb:
Nun baust Du Dir deinen eigenen Begriff ECHTE OOP
ist nicht mein Begriff:
~John schrieb:
Da wird nicht simuliert! Es ist echtes OOP!
aber ihr wißt ja besser als die Erfinder der OOP, was OOP ist ...
Ein System, das nicht einmal Buch über diejenigen Objekte führt, die es anlegt oder löscht, ist jedenfalls keine OO im Sinne, in dem etwa Smalltalk OO ist. Von der Syntax ganz zu schweigen - OOP besteht eigentlich im Kern im Senden von Nachrichten an Objekte. Dazu muß aber erstmal alles Interessante (Zahlen, Klassen, Funktionen, ...) auch als Objekt implementiert sein. So etwas ist mit einem Sprachkonzept wie C++ nur unter großen Schwierigkeiten (STL, boost) anzunähern.
Dennoch ist interessant zu beobachten, wie groß das Bedürfnis nach "mehr OOP" in der C++-Gemeinde ist - warum sonst würde man wohl solchen Aufwand treiben, nur um ein paar Krümel dessen zu bekommen, was man bei Smalltalk, also sozusagen im syntax-free-shop, seit über drei Jahrzehnten umsonst bekommt.
volkard schrieb:
Er hat recht. Aufrufen des Destruktors ist was ganz anderes als AUfrufen von delete.
Darum ging es aber nicht. Es ging um automatisch verwaltete Resourcen - in dieser Hinsicht ist C++ nicht wirklich epochemachend, wie bspw. die Abwesenheit einer GC zeigt.
-
u-ser_l schrieb:
nur um ein paar Krümel dessen zu bekommen, was man bei Smalltalk, also sozusagen im syntax-free-shop, seit über drei Jahrzehnten umsonst bekommt.
wobei "umsonst" hier nicht im finanziellen Sinn zu verstehen ist, sondern im Sinne von "ohne syntaktischen Aufwand"
-
u-ser_l schrieb:
Ein System, das nicht einmal Buch über diejenigen Objekte führt, die es anlegt oder löscht, ist jedenfalls keine OO im Sinne, in dem etwa Smalltalk OO ist.
Ach, Du spielst auf den ausgezeichneten Abschnitt über die Speicherverwaltung in http://de.wikipedia.org/wiki/Objektorientierung an, wo explizit gesagt wird, daß ein Garbage-Collector notwendig ist, um objektorientiert zu programmieren?
Objekte in lokalen Variablen oder Attributen müssen nicht verwaltet werden, denn der Compiler kann leicht an geeigneten Stellen im Code deren Zerstörung veranlassen.
Objekte im Freispeicher werden normalerweise eh in Containern verwaltet, denn man will ja damit was anstellen. Wozu sie zusätzlich nochmal verwalten lassen?
Zur Not inkludiert man einfach smart/shared/dumb/cool/disgusting-RAII-pointers.hpp
-
Dazu muß aber erstmal alles Interessante (Zahlen, Klassen, Funktionen, ...) auch als Objekt implementiert sein. So etwas ist mit einem Sprachkonzept wie C++ nur unter großen Schwierigkeiten (STL, boost) anzunähern.
Also schwierig finde ich das nicht. Man baut sich einfach einen Wrapper für die Zahlen usw. Alle neuen Compiler optimieren dies dann auch wieder raus. Kostet einen einmalig 5 Minuten Tipparbeit.
Was du damit meinst, dass man Klassen und Funktionen als Objekte implementieren soll verstehe ich nicht.
-
u-ser_l schrieb:
volkard schrieb:
Nun baust Du Dir deinen eigenen Begriff ECHTE OOP
ist nicht mein Begriff:
~John schrieb:
Da wird nicht simuliert! Es ist echtes OOP!
Das war erst 21 Jul 2009 21:50
Du hast angefangen 21 Jul 2009 09:35
-
user-l wir behaupten nicht mehr Ahnung von OOP zu haben, als die, die sich das Konzept erdacht haben, wir behaupten mehr Ahnung von OOP zu haben als du.
In java musste nix von hand freigeben, vor allem nicht 'ständig'.
In Java:
Dynamischer Speicher: nein, alle anderen Resourcen(alle Arten von Streams z.B. Dateien, Netzwerkstreams..): ja
In C++ unter zu Hilfenahme von Bibliotheken(sag mir mal was daran schlecht ist, wenn eine Sprache mächtig genug ist, dass man sich Features nachbauen kann?):
Dynamischer Speicher: nein, alle anderen Resourcen: nein.Darum ging es aber nicht. Es ging um automatisch verwaltete Resourcen - in dieser Hinsicht ist C++ nicht wirklich epochemachend, wie bspw. die Abwesenheit einer GC zeigt.
Argumente bitte, keine leeren Aussagen
-
++fricky schrieb:
also wenn es kein sprachmittel ist, dann hat man sich in C++ leider doch keine gedanken gemacht, sondern hat es libraries überlassen.
Ähm, das hast du falsch verstanden. Die Sprache ermöglicht solche Konstruktionen - etwa im Gegensatz zu C - und bildet damit die Grundlagen für RAII. Ein Destruktor, der beim Verlassen des Scopes automatisch aufgerufen wird, ist leider ein Sprachfeature.
u_ser-l schrieb:
mag sein. Wenn man alle selten vorkommenden Situationen nicht mehr als Problem auffaßt, vereinfacht sich manches. Auf Kosten der Stabilität und Vorhersagbarkeit.
Noch viel einfacher wird es allerdings, wenn man sich auf Anwendungsfälle bezieht, die bei erfahrenen Programmierern nie vorkommen, aber grundsätzlich möglich und somit Zeichen einer unüberlegten Programmiersprache sind.
u-ser_l schrieb:
Ein System, das nicht einmal Buch über diejenigen Objekte führt, die es anlegt oder löscht, ist jedenfalls keine OO im Sinne, in dem etwa Smalltalk OO ist.
C++ ist weder Smalltalk, noch hat es den Anspruch, "rein" objektorientiert zu sein. Extreme sind sowieso nicht automatisch von Vorteil. Ich weiss gar nicht, wieso du deshalb die ganze Zeit an deiner Definition von "echter OOP" festhältst, diese verallgemeinerst und als Grundlage für deine Urteilsbildung nimmst.
Wird es eigentlich langsam zur Gewohnheit, immer auf den in der Praxis am wenigsten relevanten, aber theoretisch möglichen Fallgruben von C++ rumzureiten? Ich meine jetzt solche Dinge wie mehrfache Destruktoraufrufe, absichtlich umgangene Typsicherheit und
volatile int*-Überladungen.
-
u_ser-l schrieb:
zur Laufzeit sollte trotzdem eine Beschwerde kommen, wenn versucht wird, eine Methode oder gar den D.tor eines Objekts aufzurufen, welches bereits Destruiert worden ist.
ISO Standard 14882, §12.4, Absatz 14 schrieb:
Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended (3.8).
ISO Standard 14882, §3.8, Absatz 1 schrieb:
The lifetime of an object of type T ends when:
— if T is a class type with a non-trivial destructor (12.4), the destructor call starts, or
— the storage which the object occupies is reused or released.ISO Standard 14882, §1.3.12 schrieb:
undefined behavior
behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. [...][Note: permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).Du willst also, dass es generell kein undefiniertes Verhalten gibt, sondern jeder noch so dumme Fehler (mehrfaches Aufrufen eines Destruktors gehört definitiv dazu, die einzige Situation, die ich kenne, in der man überhaupt auf so eine Idee kommen würde, hängt mit placement-new zusammen, wenn man es also doch mal tut, sollte man wissen, was man tut) diagnostiziert? Das ist nämlich (wie hier auch schon einige Leute geschrieben haben) unmöglich oder (wie in diesem Beispiel) mit zusätzlichen Kosten verbunden, die man nicht Zahlen möchte, weil diese Überprüfung in 99,999% der Fälle einfach sinnlos wäre.
Felix
<Flame>Vielleicht neigen kompliziert denkende Menschen (die sich also mehr Gedanken um die Sprachwahl machen und nicht blind einem Guru/Hype folgen) zu C++?
</flame>
-
++fricky schrieb:
In java musste nix von hand freigeben, vor allem nicht 'ständig'.
Wieder jemand der ständig Resourenlöcher in Java produziert, weil er es nicht verstanden hat die notwendigen finally {foo.dispose()} Blöcke einzufügen. In Java muß Resourcen wieder von Hand explizit freigeben. Das trifft nicht auf den Arbeitsspeicher zu, aber auf alle anderen Resourcen. Gegenüber C++ mit RAII ein massiver Rückschritt.
-
u_ser-l schrieb:
mag sein. Wenn man alle selten vorkommenden Situationen nicht mehr als Problem auffaßt, vereinfacht sich manches. Auf Kosten der Stabilität und Vorhersagbarkeit.
Solche Aussagen können nur von jemanden kommen, der C++ wirklich nicht kennt! Hier werden Dinge zu Problemen erhoben, die in C++ nie ein Problem waren. Das explizite Aufrufen des Destruktors benutzt man nur in bestimmten Containerklassen, die man selten entwirft, da die vorhandenen in der Standardlibrary und in Boost in 99% der Fälle ausreichend sind. Wenn man es doch mal selbst machen muß, dann sichert man solche Klassen über Unittesting ab. Aber das Konzept sollte einem Smalltalk Fan wohl bekannt sein. Im Nutzcode dieser Klassen wird niemals der Destruktor explizit aufgerufen. Insofern ist das kein Problem, und hier wird das von einigen Personen zu einem künstlichem Problem erklärt.
~john schrieb:
Ja, das Konzept, von einer echten OOP zu sprechen,
In Smalltalk muß man einige Verrenkungen machen, damit man ein Singleton umsetzen kann. Die ganzen Designschwierigkeiten in Smalltalk bestimmte Design Patterns zu realisieren finden sich in "The Design Patterns Smalltalk Companion". Ist wegen dieser Probleme mit elementaren OOP Patterns Smalltalk etwa keine OOP Sprache?
u_ser-l schrieb:
eben. Deshalb muß sich C++ ja auch nicht darum kümmern
In C++ muß man unter bestimmten Umständen nur saubere Destruktoren zur Verfügung stellen. Das ist weit aus besser, als das angebliche so viel einfachere Java & Co. bei dem man wieder auf händische Verwaltung der Resourcen (es gibt nicht nur Arbeitsspeicher) zurückgeworfen ist.
u_ser-l schrieb:
Wozu brauchst du denn in deinem Codebeispiel im K.tor und D.tor new und delete, wenn der Compiler das doch von selbst macht ?
Weil eine Schnarchnase namens u_ser-l unbedingt C with Classes programmieren mußte.
-
u-ser_l schrieb:
aber ihr wißt ja besser als die Erfinder der OOP, was OOP ist ...
Es gibt die Erfinder von Simula, die haben OOP erstmals umgesetzt, und dann gibt es Alan Kay, der meint das einzig wahre OOP definiert zu haben. Nach meinem Empfinden gibt es ein Problem mit Alan Kay und mit dir, und nicht mit den Erfinder von Simula, C++, …
u-ser_l schrieb:
Ein System, das nicht einmal Buch über diejenigen Objekte führt, die es anlegt oder löscht, ist jedenfalls keine OO im Sinne, in dem etwa Smalltalk OO ist.
Das ist auch nur für Smalltalk Jünger ein Problem. Mit Smalltalk kann man viele Dinge nicht umsetzen, weil es die Sprache gar nicht unterstützt oder Smalltalk dafür zu langsam ist. Das wird es dann zu einem Problem, wenn so Jünger wie du den Rest der Menschheit zur einzig wahren OOP Sprache zwingen wollen. Denn dann kann man viele Probleme nicht mehr effizient lösen. Zum Beispiel das Laufzeitsystem von Smalltalk läßt sich nicht in Smalltalk programmieren, oder die JavaVM ist in C++ geschrieben. Schon einmal darüber nachgedacht warum das so ist?( Offensichtlich nicht, denn dann würdest du nicht so einen Unsinn von dir geben.) Dafür ist man auf Sprache wie Ada, C, C++, Fortran, … angewiesen. Smalltalk kann daher keine Universalsprache sein, die man für alle Probleme nutzen könnte. In aufgeführten Sprachen sind einige OOP Patterns schwierig und zum Teil mit erheblichen Aufwand umzusetzen, aber es ist möglich. Der Gegenpol ist Smalltalk, da kann man viele Probleme gar nicht lösen.
u-ser_l schrieb:
Dazu muß aber erstmal alles Interessante (Zahlen, Klassen, Funktionen, ...) auch als Objekt implementiert sein.
Und das ist exakt die Ursache, weshalb Smalltalk nicht fürs Number Crunching geeignet ist. Das dynamic dispatching ist einfach unerträglich langsamer als die direkten Funktionsaufrufe in C++. Normale Methodenaufrufe in C++ sind gleich schnell wie normale C-Funktionen, statisch dispatchte Aufrufe sind etwas langsamer, dynamisch dispatchte muß man von Hand nachprogrammieren und die sind so wie in Sprachen, die das direkt unterstützen, unerträglich langsam. Hast du dir jemals die Laufzeitumgebungen von Smalltalk oder Objective-C angesehen? Schon einmal darüber nachgedacht, was da für ein Hokuspokus betrieben wird, damit die Methodenaufrufen überhaupt funktionieren?
Probleme dieser Art werden üblicherweise von den wir-haben-das-einzig-wahre-OOP Apologeten einfach ignoriert und tot geschwiegen, weil man damit überhaupt nicht umgehen kann.
u-ser_l schrieb:
seit über drei Jahrzehnten umsonst bekommt.
Das ist definitiv falsch. Man bekommt es in Smalltalk eben nicht umsonst, man muß dafür einen massiven Laufzeitoverhead bezahlen. Zugegeben gibt es in C++ Bedarf an dynamic dispatching und mutiple dispatching, aber man will dafür nicht generell die Laufzeiteffizienz aufgeben, nur weil man an wenigen Stellen im Programm diese Konstrukte braucht.
u-ser_l schrieb:
Es ging um automatisch verwaltete Resourcen - in dieser Hinsicht ist C++ nicht wirklich epochemachend, wie bspw. die Abwesenheit einer GC zeigt.
Ein GC verwaltet ausschließlich Arbeitsspeicher, und ist dabei noch nicht einmal frei von Problemen: Stichwort zyklische Strukturen. Andere Resourcen werden in Sprachen mit GC überhaupt nicht verwaltet. In Java, und das ist zur Zeit eine der wichtigsten OOP Sprachen, muß man Resourcen (exklusive Arbeitsspeicher) wieder von Hand verwalten. Das sind wir doch wieder beim Niveau von Pascal angekommen, Wahnsinn was für eine bahnbrechender Fortschritt. Für mich ein deutlicher Rückschritt gegenüber C++ mit RAII.
-
Du kannst du mich so oft der Unkenntnis bezichtigen wie du willst. Nutzt gar nix. Ist schlechter Diskussionsstil. C++ ist nicht OOP in dem Sinne, in welchem etwa Smalltalk OOP ist, und kann es auch gar nicht sein, solange es Sprachmittel gibt, die erlauben, mittels Zeigern den Speicher zu manipulieren. Ist ja nicht meine Schuld
-
ich hätte noch mehr zu schreiben, aber muß jetzt mal was arbeiten, später wieder.
-
u_ser-l schrieb:
Du kannst du mich so oft der Unkenntnis bezichtigen wie du willst.
Aha, keine Argumente mehr. Die Tatsache, daß du C++ und die in C++ nicht verwendeten Konzepte nicht kennst und schon gar nicht verstanden hast, ist eine offensichtliche Tatsache. Das zeigt sich an deinen Programmbeispielen.
Es wäre so einfach zu zeigen, daß man in Java Resourcen nicht von Hand explizit verwaltet, wenn es denn der Wahrheit entspräche. Offensichtlich ist nur, daß du und andere keine konkreten Beispiele bringen, wie man es denn ohne explizite Freigabe von Resourcen hinbekommt.
-
u_ser-l schrieb:
C++ ist nicht OOP in dem Sinne, in welchem etwa Smalltalk OOP ist, und kann es auch gar nicht sein, solange es Sprachmittel gibt, die erlauben, mittels Zeigern den Speicher zu manipulieren.
Spätestens wenn du selbst zu linguistischen Workarounds wie "OOP in dem Sinne, in welchem" greifen mußt, solltest du doch mal beginnen, deinen Standpunkt infrage zu stellen
Was du ansprichst, hat mit objektorientierter Programmierung nichts zu tun. Das fragliche Kriterium nennt sich Typsicherheit; C++ ist nicht typsicher, Java schon, und Smalltalk vermutlich auch. Das ist in der Theorie ein wichtiger Aspekt, weil Typsicherheit WPO und allgemein Optimierungen signifikant vereinfacht. (In der Praxis sind die am besten optimierenden Compiler dennoch C++-Compiler
)
-
Man kann aber auch verstehen wollen, was u_ser-l gemeint hat.
Das OOP- Zeugs bei C++ ist C-Syntax- mäßig in die Sprache geflickt und bietet nicht die extreme Flexibilität zur Laufzeit wie z.B. Smalltalk oder die Objective-C- OOP. Die Versuche, C++ mit late binding aufzubohren, sind schon von Berufeneren als mir als krude und halbgar kritisiert worden.
Dafür kann man mit C++ auch hardwarenahe Treiber schreiben - das soll mal jemand mit Smalltalk probieren :p .Um C++ gerecht zu werden, muß man es - wie volkard trefflich bemerkt hat - wirklich als Multiparadigmensprache sehen, es ist wie eine nahzu vollständig eingerichtete Werkstatt für Profis - so ziemlich alles geht damit. Ohne umfassende Ausbildung verlier' ich aber an der Seilsäge eher ein paar Finger, als daß ich damit Freiformen schneide. Und bis ich so alle Werkzeuge kenne, gibt es viel zu lernen - und C++ hat einen geradezu monströsen Umfang. All das brauch' ich aber nicht, wenn ich nur ein Loch in einen Karton bohren will - da reicht mir ein Bleistift. Um den Vergleich beizubehalten: Mir genügt z.B. ein kleiner, gut sortierter Werkzeugkasten, aus dem ich mich aufgabenbasierend bediene. Wenn ich am PC ein paar bunte Buttons haben will, genügen mir Delphi oder VB, seit ein paar Wochen spiel' ich auch mit Java rum. Für den Microcontroller ist C völlig ausreichend - zumindest für mich. Heißt, für meine Belange wäre C++ völlig überflüssiger Ballast.
Ich hab' mich trotzdem mal damit befasst, war so 'ne Handbedieneinheit, größtenteils in C geschrieben, bis irgendein Schlauli von Product Manager bemerkt hat, daß der Compiler jetzt auch C++ kann und die Fortentwicklung in C++ befohlen hat. Weil der ursprüngliche Programmierer das nicht so wollte, sind in der Folge nacheinander fünf, sechs andere Leute an der Sache gesessen, wobei sich immer mehr Seltsamkeiten in das Gerät geschlichen haben. Ich habe mich für die Geschichte interessiert, als ich dann die Source gesehen habe, ist mir schlecht geworden. Erstmal war der Mischmasch von C und C++ ausgesprochen unglücklich (ich hätte z.B. erwartet, daß hardwarenah alles in C bleibt, war aber nicht so) und ich mich mit völlig unterschiedlichen Programmierstilen konfrontiert sah. Die Sachen, die ich kapiert habe, fand ich zu umständlich und vieles hab' ich gar nicht erst kapiert, wie das funzen soll. Das alles natürlich aus Sicht eines C- Programmierers.
Ich mußte einsehen, daß man dazu einen Werkstattleiter braucht, das in Ordnung zu bringen und keinen Heimwerker mit Akkubohrschrauber und habe zurückgegeben. Nur - und das ist der springende Punkt - haben es die "C++ - Experten" vor mir geschafft, ein ehedem funktionierendes Gerät gründlich zu vermurksen und keiner hat den oder die Fehler gefunden. Das bedeutet, daß Leute, die C++ nicht nur können, sondern wirklich beherrschen, wohl äußerst rar sind.
Wenn etwas so mächtig ist und so viel kann, daß man kaum jemanden findet, der das souverän bedienen kann, muß es sich in der Sicht eine Frage nach dem Sinn gefallen lassen.
Vielleicht liegt ja wirklich der Sinn darin, daß die "echten Experten" was haben, damit sie sich über andere lustig machen können ... wer weiß?
-
~john schrieb:
Aha, keine Argumente mehr. Die Tatsache, daß du C++ und die in C++ nicht verwendeten Konzepte nicht kennst und schon gar nicht verstanden hast, ist eine offensichtliche Tatsache. Das zeigt sich an deinen Programmbeispielen.
Smalltalk kennt er auch nur rudimentär, sonst hätte er double dispatching schonmal gesehen und dessen Sinn verstanden.
-
pointercrash() schrieb:
Werkstattparabel
Auch völlig ohne Fachwissen würde ich in der ordentlichen Werkstatt lieber arbeiten. Da gibt es gleich fünf passende Schraubendreher und nicht nur einen, und ich kann den allerpassendsten nehmen. Ich habe einen ordentlichen Amboß, der unverständlicherweise in allen Werkzeugkästen weggelassen wurde! Einen Schraubstock. Werkbänke. Gute Beleuchtung. Staubsauger.
Und die großen elektrischen Maschinen (vor allem die elektrische Hobelbank) machen mir doch Angst, also schalte ich sie nicht an.
Aus Angst vor der Seilsäge den Raum nicht zu betreten, nee, das ist nicht mein Stil. Ich geh da einfach rein und arbeite los und schneide mir keine Finger ab.
Und wenn ich viel sägen muß, lese ich mir halt das Handbuch zur Säge durch (ja, ich lese immer die Handbücher, selbst zu einem Toaster) und finde heraus, wie man damit gescheit arbeitet, zunächst allein durch Nachdenken, danach durch gelegentliche kleine Anwendungen.
-
volkard schrieb:
pointercrash() schrieb:
Werkstattparabel
Auch völlig ohne Fachwissen würde ich in der ordentlichen Werkstatt lieber arbeiten. Da gibt es gleich fünf passende Schraubendreher und nicht nur einen, und ich kann den allerpassendsten nehmen. Ich habe einen ordentlichen Amboß, der unverständlicherweise in allen Werkzeugkästen weggelassen wurde! Einen Schraubstock. Werkbänke. Gute Beleuchtung. Staubsauger.
Und die großen elektrischen Maschinen (vor allem die elektrische Hobelbank) machen mir doch Angst, also schalte ich sie nicht an.
Aus Angst vor der Seilsäge den Raum nicht zu betreten, nee, das ist nicht mein Stil. Ich geh da einfach rein und arbeite los und schneide mir keine Finger ab.
Und wenn ich viel sägen muß, lese ich mir halt das Handbuch zur Säge durch (ja, ich lese immer die Handbücher, selbst zu einem Toaster) und finde heraus, wie man damit gescheit arbeitet, zunächst allein durch Nachdenken, danach durch gelegentliche kleine Anwendungen.200m² Werkstatt, aber wer nen Mülleimer da drin haben will, muss ihn sich selber bauen :p (zugegeben, er läuft dann immerhin hinter einem her, erkennt und vernichtet zuverlässig jeden Müll und räumt sogar das Werkzeug wieder auf)