Methoden mit bool-Parametern und "Lesbarkeit" im Kontext
-
Shade Of Mine schrieb:
@Undertaker:
Deine Trollerei in ehrendanke! endlich jemand, der das zu schätzen weiss
Shade Of Mine schrieb:
- aber ein C++ Compiler liefert kaum eine andere Fehlermeldung als ein C oder ein Java Compiler.
das ist nicht dein ernst.
oder meinst du vielleicht 'sinngemäss'?Shade Of Mine schrieb:
Da die Sprache komplexer ist, gibt es Situationen wo die Fehlermeldung komplex ist
ja, aber muss das sein? ich finde nicht. eine fehlermeldung sollte sich auf das wesentliche konzentrieren und einem nicht sämtliche fehlschläge des parsers vor die füsse werfen.
Shade Of Mine schrieb:
- aber es geht hier um simple Typenumwandlung und da sind die Fehlermeldungen mehr als deutlich.
naja, wie es aber so ist, muss man aus den ~30 zeilen, die so'n C++ compiler manchmal bei einfachen tippfehlern ausspuckt, erstmal erkennen, dass 'ne typumwandlung scheiterte. aber klar, das ist übungssache und ein erfahrener C++ coder kommt damit möglicherweise gut zurecht.
ausserdem möchte ich dich mal ganz nebenbei an den cout/volatile bug erinneren, wobei die typumwandlung zwar scheitert (falsches ergebnis), ein C++ compiler aber nicht den leisesten pieps von sich gibt.Shade Of Mine schrieb:
Es gibt nebenbei bemerkt enorm viele Plattformen wo man deutlich schlechtere Fehlermeldungen als in C++ bekommt.
welche?
btw: du musst nicht antworten (ausser vielleicht auf die letzte frage), ich will kein thread-hijacking betreiben.
-
Undertaker schrieb:
ich will kein thread-hijacking betreiben.
Danke!
-
Mr. N schrieb:
Undertaker schrieb:
ich will kein thread-hijacking betreiben.
Danke!
Es geht doch sowieso längst nicht mehr um das Ursprüngliche, es ging schließlich mal um Flags
-
Badestrand schrieb:
Mr. N schrieb:
Undertaker schrieb:
ich will kein thread-hijacking betreiben.
Danke!
Es geht doch sowieso längst nicht mehr um das Ursprüngliche, es ging schließlich mal um Flags
Ja, aber ohne künstliche Wendung zu einem "Undertaker vs C++"-Thread. Von denen gibts außerdem schon genug.
-
Badestrand schrieb:
Es geht doch sowieso längst nicht mehr um das Ursprüngliche, es ging schließlich mal um Flags
das war mal.
inzwischen geht es darum, wie man am besten die physik in's korsett einer archaischen programmiersprache zwängt und welche auswirkungen 'typsicherheit' auf den fortbestand des universums hat
und dabei möchte ich mich nicht dazwischendrängen.
-
Undertaker schrieb:
inzwischen geht es darum, wie man am besten die physik in's korsett einer archaischen programmiersprache zwängt und welche auswirkungen 'typsicherheit' auf den fortbestand des universums hat
Falsch. Typsicherheit bedeutet, dass so etwas nicht lautlos durchrennt:
speed = time / length;Das ist praktisch. In C++ müssen wir das nicht verbieten, aber wir können - und wollen.
-
Mr. N schrieb:
Undertaker schrieb:
inzwischen geht es darum, wie man am besten die physik in's korsett einer archaischen programmiersprache zwängt und welche auswirkungen 'typsicherheit' auf den fortbestand des universums hat
Falsch. Typsicherheit bedeutet, dass so etwas nicht lautlos durchrennt:
speed = time / length;Das ist praktisch. In C++ müssen wir das nicht verbieten, aber wir können - und wollen.
versteh ich das richtig? du willst typsicherheit an op-overloading (in dem fall an dem 'operator /') festmachen?
naja, und was ist, wenn 'length' 0 ist (physikalisch durchaus erlaubt, compiliert wirds fehlerfrei, aber das proggy kackt zur laufzeit ab)?
und: verbieten könnt ihr nix, vergesst nicht, dass es in C++ alle möglichen und unmöglichen type-casts gibt. selbst ein gutwilliger, allerdings auf bequemlichkeit bedachter coder, schiesst sich das beinchen weg, wie er's schon 1000 mal vorher gemacht hat.
so oder so, ich finde, ihr verlangt zu viel typsicherheit von einer sprache, die eigentlich 'weak typed' ist. aber macht nur weiter, wie gesagt, ich möchte eure diskussion nicht stören.
-
Undertaker schrieb:
Mr. N schrieb:
Undertaker schrieb:
inzwischen geht es darum, wie man am besten die physik in's korsett einer archaischen programmiersprache zwängt und welche auswirkungen 'typsicherheit' auf den fortbestand des universums hat
Falsch. Typsicherheit bedeutet, dass so etwas nicht lautlos durchrennt:
speed = time / length;Das ist praktisch. In C++ müssen wir das nicht verbieten, aber wir können - und wollen.
versteh ich das richtig? du willst typsicherheit an op-overloading (in dem fall an dem 'operator /') festmachen?
Nein. In der Physik benutzt man eben relativ oft Division. Entschuldige, dass ich ein anschauliches Beispiel wollte
Undertaker schrieb:
naja, und was ist, wenn 'length' 0 ist (physikalisch durchaus erlaubt, compiliert wirds fehlerfrei, aber das proggy kackt zur laufzeit ab)?
Länge 0 ist physikalisch nicht erlaubt. Länge 0 m... naja da sollte dann +INF m oder so rauskommen
- aber darum gehts hier ja nicht wirklich. (Willst du ablenken?)Undertaker schrieb:
und: verbieten könnt ihr nix, vergesst nicht, dass es in C++ alle möglichen und unmöglichen type-casts gibt.
Die sind aber explizit und daher weit weniger gefährlich.
Undertaker schrieb:
selbst ein gutwilliger, allerdings auf bequemlichkeit bedachter coder, schiesst sich das beinchen weg, wie er's schon 1000 mal vorher gemacht hat.
Ich behaupte, bei einer sauberen Bibliothek wird er sich dazu nicht genötigt sehen.
Undertaker schrieb:
so oder so, ich finde, ihr verlangt zu viel typsicherheit von einer sprache, die eigentlich 'weak typed' ist.
C++ ist nicht schwach typisiert. Es ist allerdings auch nicht richtig stark typisiert.
Es geht darum, die Typisierung zu nutzen - und das will ich tun. Ich zwinge dich nicht dazu, sie zu nutzen.
Du bist nicht qualifiziert zu behaupten, das sei alles unnötig. Du hast nämlich schlicht und ergreifend keine Ahnung. Sorry.
-
Mr. N schrieb:
Undertaker schrieb:
Mr. N schrieb:
Undertaker schrieb:
inzwischen geht es darum, wie man am besten die physik in's korsett einer archaischen programmiersprache zwängt und welche auswirkungen 'typsicherheit' auf den fortbestand des universums hat
Falsch. Typsicherheit bedeutet, dass so etwas nicht lautlos durchrennt:
speed = time / length;Das ist praktisch. In C++ müssen wir das nicht verbieten, aber wir können - und wollen.
versteh ich das richtig? du willst typsicherheit an op-overloading (in dem fall an dem 'operator /') festmachen?
Nein. In der Physik benutzt man eben relativ oft Division. Entschuldige, dass ich ein anschauliches Beispiel wollte
ist doch okay, brauchst dich nicht zu entschuldigen. wie fängt man unerlaubte division in C++ noch ab?
Mr. N schrieb:
Undertaker schrieb:
naja, und was ist, wenn 'length' 0 ist (physikalisch durchaus erlaubt, compiliert wirds fehlerfrei, aber das proggy kackt zur laufzeit ab)?
Länge 0 ist physikalisch nicht erlaubt. Länge 0 m... naja da sollte dann +INF m oder so rauskommen
- aber darum gehts hier ja nicht wirklich. (Willst du ablenken?)wieso sollte die länge '0' in der physik nicht existieren? wovon willst du jetzt ablenken?
Mr. N schrieb:
Undertaker schrieb:
und: verbieten könnt ihr nix, vergesst nicht, dass es in C++ alle möglichen und unmöglichen type-casts gibt.
Die sind aber explizit und daher weit weniger gefährlich.
da stimme ich dir zu, aber die gefahr ist nicht gebannt
Mr. N schrieb:
Undertaker schrieb:
selbst ein gutwilliger, allerdings auf bequemlichkeit bedachter coder, schiesst sich das beinchen weg, wie er's schon 1000 mal vorher gemacht hat.
Ich behaupte, bei einer sauberen Bibliothek wird er sich dazu nicht genötigt sehen.
wovon träumst du nachts? reale programmierer frickeln und tricksen dass sich die balken biegen. jede beschränkung, die deine lib ihnen entgegensetzt, entfacht ihren sportlichen ehrgeiz
Mr. N schrieb:
Undertaker schrieb:
so oder so, ich finde, ihr verlangt zu viel typsicherheit von einer sprache, die eigentlich 'weak typed' ist.
C++ ist nicht schwach typisiert. Es ist allerdings auch nicht richtig stark typisiert.
C++ hat das typsystem von C 'geerbt', mit ausnahme des verkrüppelten 'void*'. von 'strong typed' kann bei C++ nicht die rede sein.
Mr. N schrieb:
Du bist nicht qualifiziert zu behaupten, das sei alles unnötig. Du hast nämlich schlicht und ergreifend keine Ahnung.
deswegen sagte ich ja bereits: macht nur weiter und entschuldigt bitte Mr.N's und meinen exkurs zum thema 'typsicherheit'
-
Undertaker schrieb:
Mr. N schrieb:
Undertaker schrieb:
Mr. N schrieb:
Undertaker schrieb:
inzwischen geht es darum, wie man am besten die physik in's korsett einer archaischen programmiersprache zwängt und welche auswirkungen 'typsicherheit' auf den fortbestand des universums hat
Falsch. Typsicherheit bedeutet, dass so etwas nicht lautlos durchrennt:
speed = time / length;Das ist praktisch. In C++ müssen wir das nicht verbieten, aber wir können - und wollen.
versteh ich das richtig? du willst typsicherheit an op-overloading (in dem fall an dem 'operator /') festmachen?
Nein. In der Physik benutzt man eben relativ oft Division. Entschuldige, dass ich ein anschauliches Beispiel wollte
ist doch okay, brauchst dich nicht zu entschuldigen. wie fängt man unerlaubte division in C++ noch ab?
Falscher Typ: Compilerfehler.
Falscher Wert: So wie in C oder mit Exceptions.Undertaker schrieb:
Mr. N schrieb:
Undertaker schrieb:
naja, und was ist, wenn 'length' 0 ist (physikalisch durchaus erlaubt, compiliert wirds fehlerfrei, aber das proggy kackt zur laufzeit ab)?
Länge 0 ist physikalisch nicht erlaubt. Länge 0 m... naja da sollte dann +INF m oder so rauskommen
- aber darum gehts hier ja nicht wirklich. (Willst du ablenken?)wieso sollte die länge '0' in der physik nicht existieren?
0 ist schlichtweg keine Länge, sondern ein (dimensionsloses) Skalar.
Undertaker schrieb:
Mr. N schrieb:
Undertaker schrieb:
und: verbieten könnt ihr nix, vergesst nicht, dass es in C++ alle möglichen und unmöglichen type-casts gibt.
Die sind aber explizit und daher weit weniger gefährlich.
da stimme ich dir zu, aber die gefahr ist nicht gebannt
Es geht nicht darum, Dinge unmöglich zu machen. Es geht darum, versehentliche Fehler zu vermeiden.
Undertaker schrieb:
Mr. N schrieb:
Undertaker schrieb:
selbst ein gutwilliger, allerdings auf bequemlichkeit bedachter coder, schiesst sich das beinchen weg, wie er's schon 1000 mal vorher gemacht hat.
Ich behaupte, bei einer sauberen Bibliothek wird er sich dazu nicht genötigt sehen.
wovon träumst du nachts?
Das vergess ich morgens meistens sofort wieder. Aber danke der Nachfrage.
Undertaker schrieb:
reale programmierer frickeln und tricksen dass sich die balken biegen. jede beschränkung, die deine lib ihnen entgegensetzt, entfacht ihren sportlichen ehrgeiz
Der einfachste Weg, die "Beschränkung" der Typsicherheit zu umgehen, ist, sich an sie zu halten. Und da Programmierer faul sind... :p
Mr. N schrieb:
Undertaker schrieb:
so oder so, ich finde, ihr verlangt zu viel typsicherheit von einer sprache, die eigentlich 'weak typed' ist.
C++ ist nicht schwach typisiert. Es ist allerdings auch nicht richtig stark typisiert.
C++ hat das typsystem von C 'geerbt', mit ausnahme des verkrüppelten 'void*'. von 'strong typed' kann bei C++ nicht die rede sein.[/quote]
Also was structs angeht ist auch C stark typisiert. Und so Zeug ist in C++ eben viel wichtiger geworden als es in C je war.
Undertaker schrieb:
Mr. N schrieb:
Du bist nicht qualifiziert zu behaupten, das sei alles unnötig. Du hast nämlich schlicht und ergreifend keine Ahnung.
deswegen sagte ich ja bereits: macht nur weiter und entschuldigt bitte meinen und Mr.N's exkurs zum thema 'typsicherheit'
Es geht hier schon ewig um Typsicherheit. Wobei man sagen muss dass deine Sicht wenigstens verständlicher ist als die von Xin.
-
Undertaker schrieb:
selbst ein gutwilliger, allerdings auf bequemlichkeit bedachter coder, schiesst sich das beinchen weg, wie er's schon 1000 mal vorher gemacht hat.
Eventuell hilft dann nur noch eine zeitweilige Versetzung in die Finanzbuchhaltung :
Shade Of Mine schrieb:
Klar hat dann ein anderer Programmierer den Fehler gemacht und nicht ich - aber ich hätte ihn verhindern können. (...)
Denn im Endeffekt kostet sowas meiner Firma Geld und das ist nie gut.Undertaker schrieb:
reale programmierer frickeln und tricksen dass sich die balken biegen. jede beschränkung, die deine lib ihnen entgegensetzt, entfacht ihren sportlichen ehrgeiz.
Muss ja voll abgehen in eurer Firma.
-
Mr. N schrieb:
Es geht hier schon ewig um Typsicherheit. Wobei man sagen muss dass deine Sicht wenigstens verständlicher ist als die von Xin.
vielleicht liegt's daran, dass wir beide einfache menschen sind und deshalb leichter einen konsens finden können, als in abstrakten sphären schwebende informatiker wie shady, Xin und CStoll
wobei ich allerdings eingestehen muss, dass Xin's postings eine gewisse bewusstseinserweiternde wirkung haben, wenn man die 'richtigen filter' einschaltet.merker schrieb:
Undertaker schrieb:
reale programmierer frickeln und tricksen dass sich die balken biegen. jede beschränkung, die deine lib ihnen entgegensetzt, entfacht ihren sportlichen ehrgeiz.
Muss ja voll abgehen in eurer Firma.
ja, ist echt so. kunde XY will unbedingt 'gleich morgen' eine spezielle funktionalität haben und dann kriegt er das einfach. nicht selten bekamen wir folgeaufträge, weil wir schnell und unbürokratisch kundenwümsche erfüllten. wie schäbig die software gefrickelt ist, interessiert keinen, solange sie zuverlässig das tut, was sie tun soll.
ich persönlich finde das auch nicht gut und arbeite lieber an grösseren systemen, bei denen mehr 'architektur' gefragt ist.
aber was will man machen? kleine firma, der kunde ist könig und 'time is money'
-
Undertaker schrieb:
Mr. N schrieb:
Es geht hier schon ewig um Typsicherheit. Wobei man sagen muss dass deine Sicht wenigstens verständlicher ist als die von Xin.
vielleicht liegt's daran, dass wir beide einfache menschen sind und deshalb leichter einen konsens finden können, als in abstrakten sphären schwebende informatiker wie shady, Xin und CStoll
(Konsens?)
Undertaker schrieb:
wobei ich allerdings eingestehen muss, dass Xin's postings eine gewisse bewusstseinserweiternde wirkung haben, wenn man die 'richtigen filter' einschaltet.
Verstehe ich "bewusstseinserweiternd" richtig? :p
Undertaker schrieb:
merker schrieb:
Undertaker schrieb:
reale programmierer frickeln und tricksen dass sich die balken biegen. jede beschränkung, die deine lib ihnen entgegensetzt, entfacht ihren sportlichen ehrgeiz.
Muss ja voll abgehen in eurer Firma.
ja, ist echt so. kunde XY will unbedingt 'gleich morgen' eine spezielle funktionalität haben und dann kriegt er das einfach. nicht selten bekamen wir folgeaufträge, weil wir schnell und unbürokratisch kundenwümsche erfüllten. wie schäbig die software gefrickelt ist, interessiert keinen, solange sie zuverlässig das tut, was sie tun soll.
ich persönlich finde das auch nicht gut und arbeite lieber an grösseren systemen, bei denen mehr 'architektur' gefragt ist.
aber was will man machen? kleine firma, der kunde ist könig und 'time is money'
Für sowas find ich Perl gut.
-
Mr. N schrieb:
Undertaker schrieb:
Mr. N schrieb:
Es geht hier schon ewig um Typsicherheit. Wobei man sagen muss dass deine Sicht wenigstens verständlicher ist als die von Xin.
vielleicht liegt's daran, dass wir beide einfache menschen sind und deshalb leichter einen konsens finden können, als in abstrakten sphären schwebende informatiker wie shady, Xin und CStoll
(Konsens?)
na, wir bräuchten jedenfalls keine ~30 seiten
Mr. N schrieb:
Undertaker schrieb:
wobei ich allerdings eingestehen muss, dass Xin's postings eine gewisse bewusstseinserweiternde wirkung haben, wenn man die 'richtigen filter' einschaltet.
Verstehe ich "bewusstseinserweiternd" richtig? :p
also, wenn du so fragst - sicherlich nicht.
Mr. N schrieb:
Undertaker schrieb:
merker schrieb:
Undertaker schrieb:
reale programmierer frickeln und tricksen dass sich die balken biegen. jede beschränkung, die deine lib ihnen entgegensetzt, entfacht ihren sportlichen ehrgeiz.
Muss ja voll abgehen in eurer Firma.
ja, ist echt so. kunde XY will unbedingt 'gleich morgen' eine spezielle funktionalität haben und dann kriegt er das einfach. nicht selten bekamen wir folgeaufträge, weil wir schnell und unbürokratisch kundenwümsche erfüllten. wie schäbig die software gefrickelt ist, interessiert keinen, solange sie zuverlässig das tut, was sie tun soll.
ich persönlich finde das auch nicht gut und arbeite lieber an grösseren systemen, bei denen mehr 'architektur' gefragt ist.
aber was will man machen? kleine firma, der kunde ist könig und 'time is money'
Für sowas find ich Perl gut.
viel spass mit perl auf 'nem 16-bitter mit 8K RAM.
-
Undertaker schrieb:
Mr. N schrieb:
Für sowas find ich Perl gut.
viel spass mit perl auf 'nem 16-bitter mit 8K RAM.
Ne, da passen die Dateien, die ich verarbeiten soll, nicht rein.
-
Shade Of Mine schrieb:
Xin, du hast eine komplett andere Vorstellung von Typsicherheit (oder Physik) als jeder andere Mensch den ich kenne.
Dann kennst Du die falschen Menschen oder wohnst vielleicht auch in einem anderen Universum.
Shade Of Mine schrieb:
Dir wurden eine Menge Nachteile deines Systems gezeigt - du hast uns allesamt dafür beleidigt und die hälfte aller Argumente ignoriert.
...
Ich bin es deshalb langsam leid, dass du alle Argumente immer vollkommen ignorierst...Mir wurde vor allem nichts besseres präsentiert. Folgerichtig ignoriere ich merkwürdige Behauptungen. In diesem Posting kannst Du Dich noch nichtmals darauf einigen, ob ich "alle Argumente vollkommen" oder nur "die Hälfte" ignoriere.
Wenn Du nicht mitgezählt hast, ich habe genau ein Argument anerkannt und bin ihm durch die Einführung der Klasse Unit gefolgt. Den Rest der Diskussion kannst Du so wie sie ist in die Tonne kloppen.Shade Of Mine schrieb:
...und nur behauptest wir alle haben keine Ahnung.
Ich behaupte, dass Du nicht weißt, wovon Du sprichst und Du hast es wiederholt belegt.
Also würde ich sagen, wir sind uns in diesem Punkt einig.Shade Of Mine schrieb:
Wikipedia schrieb:
Typsicherheit bezeichnet den Zustand (einer Programmausführung), bei dem die Datentypen gemäß ihren Definitionen in der benutzten Programmiersprache verwendet werden und keine Typverletzungen auftreten. Werden dementsprechend Typfehler spätestens zur Laufzeit erkannt, spricht man von „typsicheren Sprachen“. Typsicherheit herzustellen ist Aufgabe des Compilers bzw. Interpreters.
Und hat damit eine andere Definition als du.
Nein, die Definition stimmt schon überein.
Das Problem ist nur, dass wir C++ programmieren und C++ in einem beliebig großen Typsystem leider keine typsichere Sprache ist.
Schöner Quote, leider kein Argument.Shade Of Mine schrieb:
Nur als kleiner Denkanstoss: du unterhältst dich hier nicht mit Kiddies - die meisten von uns arbeiten seit Jahren täglich mit C++ oder anderen Sprachen (Sprachen von denen du vermutlich noch nichtmal etwas gehört hast - also bezüglich Horizont erweitern und so).
Erzähl mir doch mal etwas, was ich noch nicht weiß. Ich erweitere gerne meinen Horizont. Der alte Mann und das Meer der Programmiersprachen (frei nach MrN) sind schon häufiger aufeinandergetroffen.
Shade Of Mine schrieb:
Wir wissen also sehr wohl wovon wir reden.
Da ist es wieder... das "wir". Eingelullt in einer Floskel, der selbstverständlich niemand widersprechen würde.
Shade Of Mine schrieb:
Die Masse hat natürlich nicht immer recht - aber es sollte dir dennoch zu denken geben wenn deine Ansichten komplett anders sind als die aller Anderen. Vielleicht bist du ein Genie dass einfach um Jahrzehnte uns allen voraus ist - vielleicht sind deine Ideen und Ansichten aber auch einfach nur falsch.
Vielleicht. Da meine Ideen und Ansichten funktionieren, schließe ich Möglichkeit B aus.
Möglichkeit A kann ich noch nicht beurteilen, üblicherweise sind meine Prognosen recht genau eingetroffen. Allerdings habe ich mir alleine schon über ein Jahrzehnt Zeit genommen, bevor ich mir eine erste Prognose zugetraut habe und ich habe erst zwei Jahrzehnte Erfahrung. An den Jahrzehnten arbeite ich also noch.
Frag 2017 nochmal nach.Shade Of Mine schrieb:
Ich weiß, dass mein Chef mir den Hals umdrehen würde wenn ich ihm erklären würde dass ein Fehler durch unachtsamkeit der Firma ein paar Tausend Euro gekostet hat.
Darum sagte ich Dir ja, dass Du beim Debuggen nicht Symptome, sondern Fehler bekämpfen solltest. Das spart Geld, auch wenn Du 5-10 Minuten mehr Zeit investieren musst.
Shade Of Mine schrieb:
Ein "selber Schuld" kann ich nicht anbringen. Klar hat dann ein anderer Programmierer den Fehler gemacht und nicht ich - aber ich hätte ihn verhindern können.
Du kannst keine Fehler verhindern.
Es ist eigentlich eine evolutionäre Sache: Die Evolution bringt immer bessere Entwickler heraus, die noch bessere Programme und noch bessere Libs erstellen, produziert aber gleichzeitig immer noch bessere DAUs.
Schau Dir doch mal an, was sich alles "Informatik-Student" nennt oder wie oft man auf ein geistiges Vakuum im produktiven Einsatz trifft.Ich habe kein Problem damit, einem Vollspacken zu erklären, dass er für den Beruf des Informatikers nicht geeignet ist. Und wenn Dein Chef einen Vollspacken an seine Software setzt, dann wird er Fehler machen - egal, wieviele Fehlermöglichkeiten Du abfängst: Dein Chef wird trotzdem die Erfahrung machen, dass eine Fachkraft billiger ist, als ein Vollspacken.
Schönen Gruß vom Experiment Indien.Damit ein Vollspacken weiß, warum er kein goto verwenden soll, muss er erstmal goto verwenden. Das alleine ist für mich Grund genug, dass jede Sprache über ein goto verfügen sollte.
Gebranntes Kind scheut das Feuer, aber ohne Feuer kein gebranntes Kind...Die Qualität der Programmiersprachen entwickelt sich kontinuierlich weiter, genauso die Blödheit der Nutzer dieser Sprachen. Schau Dir mal alte Literatur zu C an. Dort wird die Einfachheit und die Möglichkeiten der Sprache gelobt. Aus damaliger Perspektive ein Fortschritt. Die heutige Perspektive ist eine andere.
Überhaupt gibt es heute andere Statistiken.
So findest Du beispielsweise heraus, dass ein Assemblerprogrammierer genauso produktiv ist, wie ein C++ Programmierer, obwohl er scheinbar viel mehr tippen muss und das Ganze auch noch total unleserlich ist. Wie kommt sowas?
Die Idee, dass Assembler ineffektiv und unleserlich ist, kommt von einer Generation, die nie wirklich Assembler programmiert hat. Genauso wie die Vorstellung, dass C keine einfache Sprache sei.
Ein guter Assemblerprogrammierer wird C effektiv zu nutzen wissen, ein guter C programmierer wird C++ effektiv zu nutzen wissen. Und wer C++ gelernt hat, wird sich darüber beschweren, dass "man" in Assembler heutzutage nicht mehr arbeiten kann.
Als ich Assembler lernte, waren Computer noch lange nicht in jedem Haushalt. Für den Assembler zahlte ich noch 200 DM, der C++-Compiler des SAS-Institute kostete damals 695 DM.
Allein die Preise hielten die Spacken davon ab, einfach mal loszutexten.
Heute sind derartige Tools kostenlos. Die wichtigste Frage im C++-Forum ist vermutlich, warum nach dem Programmstart immer das Konsolenfenster sofort zugeht.Als ich mir das erste Modem kaufte - und das war spät, weil ich die Zeit davor einfach keine 1000 Mark für ein 2400er Modem nicht einsah. 9600 Baud war schnell, ich war mit einem 14400er Modem damals mit absolutem Hi-Speed unterwegs, die Dinger waren frisch auf'm Markt.
Die Übertragungsrate von bis zu 1,5kb/s war sensationell, 4 Minuten Onlinezeit kosteten 23 Pfennig - falls man eine kostenlose Gegenstelle hatte. Da sah die Onlinewelt noch anders aus.
Als Anfänger hatte man es schwer, zwischen den Informationen einen Einstieg zu finden, weil nahezu jeder der Online war wußte, was er da tat. Wenn sich jemand also die Mühe machte, etwas zu beschreiben, war das noch höheres Niveau.
Heute haben wir Breitbandzugänge mit Flatrates für alle. Jeder ist online und zwischen dem ganzen Geschwafel einen intelligenten Satz zu finden bedarf aufwendiger Suche.Der Einsatz vom Computern hat die Produktivität von Büros nachweislich verringert. Früher suchte man 30 Sekunden die Akten im Aktenschrank, heute sucht man den Admin in einer externen Firma. Früher hat man Bürokratie aus gesundem Menschenverstand beschränkt, heute erstickt man darin, weil Computer sie eben nicht bewältigen.
Wer heute einen Brief tippt und sich verschreibt, korrigiert den Brief schnell am Computer. Heute kann jeder einen fehlerfreien Brief drucken.
Leider schreiben die meisten so langsam, dass eine brauchbare Sekretären in der Zeit zwei Briefe an der Schreibmaschine getippt hätte.
Nicht alles, was als Fortschritt angesehen wird, ist auch einer.Fortschritt findet nicht nur an einem Punkt statt. Nicht nur der Punkt, der Hi-Tech markiert, verschiebt sich, sondern es folgt auch die Position, die angibt, was jetzt Standard ist.
Wenn Du es schaffst ein Problem zu lösen, fallen tausende anderer Probleme nach: was vorher Hi-Tech und wenigen vorenthalten war, wird jetzt von der Masse genutzt. Und das bringt vor allem eine Masse Dummheit mit sich.
Nun heißt es den Punkt zu finden, an dem man möglichst wenig Probleme hast, also möglichst wenig Dummheit.Und jetzt gebe ich Dir eine Prognose, die im Jahr 2017 vielleicht erkannt wird:
Fortschritt wird nicht dadurch erreicht, dass man 1 Problem löst, sondern dass man dafür sorgt, dass keine tausend Probleme nachfallen. Für die Programmiersprachen heißt das, dass der Hebel bei den Entwicklern angesetzt wird: Eine Hürde, über die die Vollspacken nicht drüber kommen.
Assemblerprogrammierer sind deswegen so überraschend effektiv, weil Assemblerprogrammierer keine Vollspacken sein können, die Hürde schafft ein Depp einfach nicht. Wer OOP in Assembler verwendet, weiß sehr exakt, was er da grade tut.
In C++ muss man nicht unbedingt so genau wissen, was man tut. Ansonsten existiert ein großer Markt an Büchern ("kein Vorwissen erforderlich"), ein Haufen halbgarer Tutorials und Foren mit tausenden von Experten.
Qualitätative Bücher hingegen lassen sich an einer Hand.Diese Prognose leite ich übrigens aus einem Buch ab, dass sich mit Programmierern auseinandersetzt: "Die Psychologie des Programmierers". Das Buch kannst Du in jeder Buchhandlung kaufen, geschrieben wurde es aber afair in den 1960ern.
Die Tatsache, dass es für jede gefundene Lösung auch mindestens ein passendes Folgeproblem gibt hält das Buch bis heute aktuell. Ich könnte mir vorstellen, dass es auch in 50 Jahren noch aktuell ist.Shade Of Mine schrieb:
Programmierer haben auch idR komplexere Probleme zu lösen als darauf zu achten ob man da jetzt einen non-explicit CTor schreiben darf (der logisch das richtige wäre) und dann noch alles richtig funktioniert oder nicht. Solche Fehler kosten Tage um sie zu finden. Und Zeit ist Geld.
Deshalb weiß ich, dass ich deinen Ansatz nie in einem produktiv System rechtfertigen kann. Es ist einfach fahrlässig statische Checks nicht einzubauen weil der Anwender des Codes gefälligst selber denken soll. Das ist eine Argumentation die nicht wirklich zieht.
Ähh... Sekunde... Du baust meine statischen Tests aus, weil Du keine expliziten Konstruktoren haben möchtest und argumentierst dann so...?
Hallo...? Echo...?
Shade Of Mine schrieb:
Deine Ansichten und Definitionen sind komplett anders als so ziemlich alles was ich je gehört habe (und ich habe schon eine Menge gehört). Das alleine sollte Grund genug sein die herkömmlichen Ansätze nicht als "dumm" hinzustellen - du stellst damit so ziemlich die gesamte Programmiererschaft der letzten 40 Jahre als dumm hin.
Expansion der ersten Person plural. Alternativ Shade im Größenwahn - als Sprecher der gesammten Programmierschaft der letzten 40 Jahre - dabei gibt's C grade mal 35. ^^
Shade Of Mine schrieb:
Es mag vielleicht sein dass wir alle Dumm sind und deine Ansätze um soviele Klassen besser sind dass Niemand den Vorteil zu sehen vermag den sie bieten - aber sind wir uns ehrlich: wie groß ist diese Wahrscheinlichkeit?
In diesem Thread?
In diesem Thread, wo hauptsächlich der Forenkindergarten Postings absetzt?
Wo der Fragesteller gegen sich selbst argumentiert und ernsthaft auch noch glaubt das wäre ein kluges Argument?
Unter der Berücksichtigung, dass ich eigentlich sehr kritisch bin und weiß, warum ich für meine Sprache Lösungen suchen musste, die ich in C++ nicht ausdrücken kann, um dem Problem zu begegnen?
Wie hoch könnte sie sein?
Wenn man davon ausgeht, dass es immer ein theoretisches Epsilon gibt...Nein, bleiben wir realistisch... CStoll hat den Vorteil erkannt. Er macht schließlich das gleiche wie ich und ich habe nie verboten, meine Klassen über Templates zu erzeugen. Dass er seine Klassen über ein Template erzeugt bringt ihn halt auch nicht weiter.
Ich bin nicht sicher, aber aktuell glaube ich, dass Du der einzige bist, der nicht kapiert, dass in C++ "soviele" Typen auch entsprechend "soviele Klassen" benötigen - und das ist keine Frage der Wahrscheinlichkeit - das ist einfach so...Undertaker schrieb:
wobei ich allerdings eingestehen muss, dass Xin's postings eine gewisse bewusstseinserweiternde wirkung haben, wenn man die 'richtigen filter' einschaltet.
Hehehe, nett ausgedrückt.
Unabhängig, ob Du Dich mit meinen Aussagen anfreunden kannst oder nicht, ich freue mich über jeden, der mit offenen Sinnen durch die Welt zieht.
-
ROFLMAO
Sei froh, daß es hier keinen Kindergarten gibt, sonst würdest Du spätestens jetzt im Mülleimer stecken
Hast Du inzwischen wenigstens enum verstanden? Oder das "2 + 2 = 5"-Beispiel aus dem anderen Thread? Ach was solls, schreib Deinen plattformunabhängigen Assembler fertig und beeindruck damit Deine Tutanden. Viel Spaß noch beim weiteren Leben unter der "Informatiker(=>Softwareentwickler)"-Käseglocke.
-
Xin schrieb:
Fortschritt wird nicht dadurch erreicht, dass man 1 Problem löst, sondern dass man dafür sorgt, dass keine tausend Probleme nachfallen.
Für die Programmiersprachen heißt das, dass der Hebel bei den Entwicklern angesetzt wird: Eine Hürde, über die die Vollspacken nicht drüber kommen.Das lässt nur Böses ahnen über die zukünftige Syntax der Programmiersprachen.
Fehlervermeidung durch Reduzierung potentieller Fehlerverursacher ist kein Fortschritt sondern das genaue Gegenteil davon.Xin schrieb:
Als ich Assembler lernte, waren Computer noch lange nicht in jedem Haushalt.
Für den Assembler zahlte ich noch 200 DM, der C++-Compiler des SAS-Institute kostete damals 695 DM.
Allein die Preise hielten die Spacken davon ab, einfach mal loszutexten.Da haben wir es ja wieder : "Früher war alles viel besser".
-
@Xin: ich als "A-Prollo des Forums", der mittlerweile - dank scrub - eh nichts zu verlieren hat, bezeichne _dich_ als Vollspacken der in seinem Kindergarten lebt. Ja. Einfach mal so. Just for fun. Weil es mir halt eben danach ist. Vielleicht aber auch weil ich von einem anderem Planeten komme. Such' es dir ruhig aus.
Ganz ehrlich, deine Ausraster sind fuer meinen Geschmack unverzeilich. Viel zu schnell nimmst Du sachliche Kritik an dir als eine Beleidigung wahr und konterst auch entsprechend. Voellig unberechtigt. Ist das Ego eines FH-Absolventen wirklich derart schaebig, dass es der Kritik eines Uni-Stundenten nicht Stand halten kann?
-
Ist das Ego eines FH-Absolventen wirklich derart schaebig, dass es der Kritik eines Uni-Stundenten nicht Stand halten kann?
aha, mhm, aah, ich merke.
