Programmier-"Niveau"
-
Sorry deine Thread haben viel zu viel raschen als, dass man sich die durchlesen sollte. Wenn man sich intensive beschäftigt und darüber redet, wird man nicht daran rumkommen, eine Definition mit ein einem Name zu versehen. Sonst gibst einfach zu viel Redundanz in der Nachricht.
Ich sehs schon
Das Pattern, dass so Aussieht und dem Zweck dienst ist orthogonal zu dem, dass für dies und das entwickelt.Anstatt zu sagen
A ist orthogonal zu B entwickelt.
-
ScottZhang schrieb:
Ja genauso hab ich das gemeint. Schade, dass das nicht klar rübergekommen ist.
Diese Buzzwörter zu kennen heßt nix anderes als die Codepages gelesen zu haben, in deiner Analogie. Man kennt diese Buzzwörter nur wenn man kommuniziert.Darum sind das eben nicht nur tolle Begriffe für möglicherweise triviale Sachen, die man getroßt ignorieren kann. Dahinter verbirgt sich der Stand der Technik ...
Die Umschreibung finde ich gut. "Dahinter verbirgt sich der Stand der Technik."
Ich sehe das anders. Ich denke, dass die Technik sich in den letzten Jahren etwas umstrukturiert hat, aber im Prinzip unverändert ist. Computer werden schneller, Hilfsprozessoren wie GPUs spezialisieren sich für gewisse Aufgaben. Java und .NET ist Technik aus den 60ern, Hilfsprozessoren waren in den 80ern schon Stand der Technik, zum Beispiel als eine CPU noch nicht zwangsläufig eine FPU oder MMU besaß.
Ich bin seit 1985 mit Computern unterwegs. Ist seit der Jahrtausendwende irgendetwas bemerkenswertes passiert? Hab ich was verpasst? Wir haben uns Ende der 90er in die 70er zurückgebeamt und befinden uns auf der Zielgrade zurück in die 90er. Der Stand der Technik findet sich irgendwo Mitte der 90er. Ich vermute in etwa 10 Jahren sind wir da angekommen. Das ist für mich persönlich blöd, weil bisher konnte ich über 15 Jahren sagen, wie die Zukunft aussieht, in 10 Jahren muss ich vermutlich selber darüber nachdenken.
Seit meinem Studium wird mir der Stand der Technik nur in leeren Worthülsen verkauft. Ich möchte nicht wissen, wieviel Zeit ich für Begriffe wie RAII, Closure, Metaprogrammierung etc. verschwendet habe, auf der Suche nach der großen Neuerung und eigentlich immer nur heiße Luft... mal eine Vereinfachung, aber in der Regel nur ein Name für irgendwas, was es schon lange gab - nur halt nicht unter dem Namen.
Software wird besser bedienbar, zuverlässiger, aber sie erfindet sich nicht neu. Vor allem wird sie klobiger.Was ist mit den Menschen, die Bedeutungen kennen, aber nicht die Worte dafür, die in der Gegenwart modern sind? Der Stand-der-Technik sind in der Regel nur eine neue Codepage, aber dahinter verbirgt sich der gleiche Kram wie zuvor.
Mein derzeitiges Lieblingswort ist "die Cloud". Heute speichert man nicht mehr altmodisch Daten mit (S)FTP auf einem Internetserver. Heute speichert man in der Cloud. ^^
Als ich im Studium war, gab es noch keine Cloud. Aber wenn zwei Rechner über ein Netzwerk verbunden waren, dann führte man auf einer Konzeptzeichnung von beiden eine Linie in einen wolkenartigen Kringel. Und während ich zu Hause nur ein altmodisches NAS stehen habe, hat ein Freund von mir schon ein NAS mit Cloud-Funktion... Bingo!
Zeus schrieb:
Sorry deine Thread haben viel zu viel raschen als, dass man sich die durchlesen sollte. Wenn man sich intensive beschäftigt und darüber redet, wird man nicht daran rumkommen, eine Definition mit ein einem Name zu versehen. Sonst gibst einfach zu viel Redundanz in der Nachricht.
Ich würde das nicht als Rauschen bezeichnen, sondern als Griff. Du hast mein Posting zwar gut zusammengefasst, aber der Zusammenfassung fehlt, dass es einen Grund gibt und bereits Lösungen in technischen Kommunikationsprotokollen. Für die meisten Leser ist eine derartige Zusammenfassung ein Satz, der da halt so rumsteht. Er kommt auf den Punkt, aber er zeigt nicht, von wo er kommt und er weist nirgendwo hin. Es ist eine Ortsangabe und kein Weg.
Die Bedeutung ist vergleichbar, aber es ist nicht zu Begreifen.
-
Xin schrieb:
Zeus schrieb:
Sorry deine Thread haben viel zu viel raschen als, dass man sich die durchlesen sollte. Wenn man sich intensive beschäftigt und darüber redet, wird man nicht daran rumkommen, eine Definition mit ein einem Name zu versehen. Sonst gibst einfach zu viel Redundanz in der Nachricht.
Ich würde das nicht als Rauschen bezeichnen, sondern als Griff. Du hast mein Posting zwar gut zusammengefasst, aber der Zusammenfassung fehlt, dass es einen Grund gibt und bereits Lösungen in technischen Kommunikationsprotokollen. Für die meisten Leser ist eine derartige Zusammenfassung ein Satz, der da halt so rumsteht. Er kommt auf den Punkt, aber er zeigt nicht, von wo er kommt und er weist nirgendwo hin. Es ist eine Ortsangabe und kein Weg.
Die Bedeutung ist vergleichbar, aber es ist nicht zu Begreifen.Ich glaub nicht, dass du mein Punkt verstanden hast, du willst hier etwas jemand beibringen, etwas vermitteln? Ich hätte Shade kurzfassung im ersten lesen total zugestimmt - eh? Dabei hast du doch etwas anders geschrieben. Du rauscht! Bloß wessen problem ist das? Ich glaub nicht meins, immerhin muss du den Walltext hier hinterschieben.
-
Habt ihr noch immer nicht genug von dem Thema Niveau?
Nach meinem Sprachverständnis zeichnet Niveau (französisch) so etwas wie level (englisch) oder Höhe (deutsch) aus. Egal in welcher Sprache, es muss einen Bezug zum Messen - also eine Messlatte mit einer Messvorschrift - geben. Wer als Programmierer 'Hello World' ohne fremde Hilfe hinbekommt, kriegt 1 Punkt von 100
-
Zeus schrieb:
Ich glaub nicht, dass du mein Punkt verstanden hast, du willst hier etwas jemand beibringen, etwas vermitteln? Ich hätte Shade kurzfassung im ersten lesen total zugestimmt - eh? Dabei hast du doch etwas anders geschrieben. Du rauscht! Bloß wessen problem ist das? Ich glaub nicht meins, immerhin muss du den Walltext hier hinterschieben.
Du hast recht... ich habe keine Ahnung, worauf Du Dich gerade beziehst und ich verstehe Dich nicht.
Ich möchte jemandem etwas beibringen? ... und wem? Die Frage kannst Du auch als "Nein" auffassen, bisher findet hier nur eine Unterhaltung statt.Walltext? Ein Gedanke, der länger als ein einzelner Satz ist, ist für Dich Rauschen? Verstehe ich das so richtig? Und das wäre dann mein Problem? Ich gehe davon aus, dass ich das hier falsch verstehe.... oder hoffe es zumindest...
Vielleicht fügst Du Deinem Punkt auch etwas mehr "Rauschen" hinzu. Setzt Deinen Punkt in Beziehung, spannst Deinem Gedanken eine Dimension auf, beschreibst, wo Dein Punkt herkommt und wo Du eigentlich mit seiner Erwähnung hinwillst. Ich glaube, dann verstehe ich Dich besser. Dafür wäre aber etwas mehr Text erforderlich.
-
Was ein nerviger Thread. Immer im NadrW ganz oben, dabei diskutiert ihr hier nur ueber irgendwelchen Bullshit. Und das 24/7.
-
Xin schrieb:
Jemand hier, der einen std::vector schonmal für die Vektorrechnung benutzt hat? ^^
Wir hatten ein Projekt das von einem externen entwickelt wurde der das neben der Uni her gemacht hat und gleichzeitig noch ein Buch darüber geschrieben hat.
War ein 3D Spiel das auf nem Automaten lief.
Der hat überall 3 Element grossestd::vector<float>als 3D-Vektoren hergenommen.
Überraschenderweise war das Ding ein bisschen langsam *g*.
-
Hi,
irgendwie wird hier ziemlich auf abgehobenem Niveau diskutiert ohne auf das wesentliche zu kommen.
Sinn von Programmen ist es weder mit RAII zu verwenden, noch auf Pattern zu basieren, sondern ganz einfach eine jeweils gegebene Aufgabe möglichst perfekt zu erfüllen.Ich kenne da einen Fall einer "ganz renomierten Edelschmiede", die auf solche Formalismen sehr viel Wert legt.
Aber wenn ein simpler Benutzer wissen muss, dass er bei einer bestimmten Eingabe bei einer Reihe von Checkboxen z.B. von der 14 bis zur 19 (die nicht mal durch ne Linie abgetrennt sind) ein Kästchen, und zwar genau eins und nicht null oder zwei ankreuzen muss, dann gehört das den Entwicklern so lange um die Ohren geschlagen bis sie ihren Job wegen durch die Schläge verursachtem Parkinson augeben müssen.Dass ein Programm (in der Mehrzehl der Fälle) richtig rechnen muss ist klar, darüber brauchen wir nicht zu reden. Auch wenn z.B. viele Steuerberatungsprogramme noch nicht mal dieser Anforderung nachkommen.
Aber wie das intern gemacht wird, ist von der konkreten Sache abhängig.
Wenn ich mir mal schnell ein Werkzeug zusammenfrickle, um damit eine spezielle Aufgabe zu lösen, dann sieht das schon mal ein wenig improvisiert aus (auch intern). Wenn ich dagegen ein Programm an private Nutzer wo hunderte damit rechnen rausgebe, muss es absolut stabil laufen und möglichst idiotensicher sein. Gebe ich es aber nur an 2-3 Ämter raus, kann ich eventuell mit der einen oder anderen Nachfrage leben. Ist es für den Kollegen im Nachbarzimmer, kann ich mir viele Sachen sparen, weil der im Notfall mal rüberkommen kann. Wenn er es aber als Dauerarbeitsinstrument benutzen soll, und nicht nur für eine eimalige Sache, dann muss es auch wieder großen Wert auf Stabilität und bedienfreundlichkeit legen.Ich gebe zu, dass bei den Sachen, die ich hier mache auch ein paar Sachen dabei sind, die ich überhaupt nicht richtig begriffen habe wie sie funktionieren. Aber es waren Programme die sich bewärt haben und unter dBase oder Foxpro oder ähnlichem liefen und die auf neue Umgebungen (Delphi) umgestrickt wurden. Ich bin davon ausgegangen, dass der Rechenalgoritmus schon stimmen wird, und dass die, die dafür verantwortlich waren das damals richtig gemacht haben. Wenn sie mal generell neu gemacht werden, dann wird auch darüber zu befinden sein, aber im Moment wäre es unnötiger Luxus.
Auch arbeite ich vielfach, wo es keine weiteren Folgen hat einfach mit leeren try except-Blöcken. Bei einem Syntax-Highlighting macht es nichts wenn unter bestimmten Bedingungen das Ding was vergisst. Wenn ich dagegen was zu berechnen habe, dann muss ich mir schon gedanken machen, was bei einem Fehler passieren sollte. Aber gerade, wenn auf was aufaddiert wird, und bei ner Division durch null ist nichts aufzuaddieren, dann spare ich mir da auch gleich mal ne Reaktion, weil ja das Übergehen des Eintragens schon ausreichende Reaktion ist.
Auch die allgemeine Regel dass Klammern nicht mit Leerzeichen abgetrennt werden verwende ich nicht. Ich arbeite mit meiner Software alleine, und empfinde es als übersichtlicher. Aber das sid alles Sachen, die nur gehen, weil ich der einzige neben Kollege Compiler bin, der mit meinem Quelltext umgehen muss.
Würde ich in einem Team arbeiten, wären das natürlich alles wichtige Dinge, weil es hilft, den innerbetrieblichen Kontakt zu optimieren. Wenn man mit anderen zusammen arbeitet, und jeder muss sich für jeden auf einen anderen Stil einstellen, dann hat man mehr mit umdenken zu tun als mit programmieren. Aber selbst das ist bewältigbar, wenn man ältere Kollegen im Team hat, die man nicht mehr umkrempeln kann, die aber ansonsten gut arbeiten. Dann schafft man eben definierte Schnittstellen, und jeder ist in seiner Box zu Hause und selbst verantwortlich. (Problem nur, wenn der Kollege mal geht) Mehr als persönliche Schrullen würde es mich stören, wenn der Kollege z.B. noch nie Scott Meyers gelesen hätte.
Aber das alles entscheidet letztlich nicht über den Erfolg eines Programms. Ein gutes Programm muss es dem Nutzer nicht nur ermöglichen damit zu arbeiten, sondern muss sich ihm aufdrängen. Es muss erreichen, dass der Nutzer damit arbeiten WILL. Da ist das eine, dass es eine aufgeräumte Oberfläche hat, wo der Nutzer immer sieht wo er ist und was er gerade macht und was er tun könnte, es muss handlich sein... aber es muss dem Nutzer auch auf SEINEM Gebiet entgegen kommen. Wenn also z.B. Angaben für den Nutzer in Zoll bereitstehen, dann ist es nicht sehr weiterführend von ihm zu erwarten dass er in cm umrechnet. Es sind viele Sachen, auf die man als Nur-Programmierer gar nicht kommt, die aber im praktischen Einsatz über wirklichen Nutzwert entscheiden.
Also nicht die Akademische Glocke zu hoch hängen, sondern vor allem an den Nutzer denken, der damit arbeiten will/soll. Und vor allem bei aller Perfektion die Lebensdauer und Nutzungshäufigkeit mit überdenken. Bei einem Programm das einmal rechnet ist es egal, wie lange das dauert. Bei einem welches jeden Tag oft verwendet wird, ist es mit die wichtigste Eigenschaft.
Gruß Mümmel
-
@muemmel
Es gibt nunmal bestimmte Dinge die ein Programm unübersichtlich und unwartbar machen.
Manuelle Resourcenverwaltung gehört da dazu.
Da braucht es schon sehr gute und vor allem disziplinierte Programmierer damit das leserlich und wartbar und korrekt bleibt.
Dummerweise sind genau die Programmierer die kein RAII verwenden üblicherweise auch die die nicht besonders gut und/oder diszipliniert sind.
Wären sie nämlich beides, dann würden sie verstehen was es bringt, und würden ggf. vermutlich auch nicht davor halt machen mal ein paar Stunden oder gar 1-2 Tage ihr Hirn einzuschalten während sie sich in das für sie neue Thema einarbeiten.
Wobei RAII hier nur ein Beispiel ist. Eine weitere Sache ist z.B. Code-Duplizierung zu vermeiden bzw. auch Strukturierung. Man mag es nicht glauben, aber es gibt Programmierer die ab einer bestimmten Projektgrösse anscheinend Angst bekommen neue Funktionen zu definieren. Die schreiben dann einfach Code in Funktionen dazu. (BTW: ich sitze gerade vor einem so entstandenen 2000 Zeilen Funktionsmonster. *Freude*)Schlechte Programmierer dagegen schreiben schlechten Code.
Wobei "schlecht" hier eine bewusste Vereinfachung ist. Letztlich ist mir auch egal warum ein "schlechter" Programmierer schlechten Code schreibt. Wenn er blitzgescheit ist, aber aus irgend einem anderen Grund total unwartbaren Code schreibt ist er trotzdem ein schlechter Programmierer.Und daran ändert sich auch nix wenn du bestimmte Dinge als "zu hoch gehängte Akademische Glocke" bezeichnest.
Die wenigsten unwartbaren Programme sind für den Benutzer gut. Vorausgesetzt das Programm wird lange genug "gewartet" (=über Monate oder Jahre hinweg immer wieder erweitert/geändert) ergibt sich irgendwann mal ein so verbuggter und inkonsistenter Dreckshaufen dass kein User gerne damit arbeiten mag. Also ist es IMO eine Voraussetzung halbwegs sauberen Code zu schreiben, wenn man ein gut bedienbares Programm haben will. Es ist aber eben auch nur eine Voraussetzung, und für sich genommen noch nicht ausreichend.
Und nachdem das Thema hier das Programmieren war, und nicht User-Interface-Design, würde ich mal sagen: deine Einwände sind völlig off-topic
-
@muemmel
Es gibt nunmal bestimmte Dinge die ein Programm unübersichtlich und unwartbar machen.
Manuelle Resourcenverwaltung gehört da dazu.
Da braucht es schon sehr gute und vor allem disziplinierte Programmierer damit das leserlich und wartbar und korrekt bleibt.
Dummerweise sind genau die Programmierer die kein RAII verwenden üblicherweise auch die die nicht besonders gut und/oder diszipliniert sind.
Wären sie nämlich beides, dann würden sie verstehen was es bringt, und würden ggf. vermutlich auch nicht davor halt machen mal ein paar Stunden oder gar 1-2 Tage ihr Hirn einzuschalten während sie sich in das für sie neue Thema einarbeiten.
Wobei RAII hier nur ein Beispiel ist. Eine weitere Sache ist z.B. Code-Duplizierung zu vermeiden bzw. auch Strukturierung. Man mag es nicht glauben, aber es gibt Programmierer die ab einer bestimmten Projektgrösse anscheinend Angst bekommen neue Funktionen zu definieren. Die schreiben dann einfach Code in Funktionen dazu. (BTW: ich sitze gerade vor einem so entstandenen 2000 Zeilen Funktionsmonster. *Freude*)Schlechte Programmierer dagegen schreiben schlechten Code.
Wobei "schlecht" hier eine bewusste Vereinfachung ist. Letztlich ist mir auch egal warum ein "schlechter" Programmierer schlechten Code schreibt. Wenn er blitzgescheit ist, aber aus irgend einem anderen Grund total unwartbaren Code schreibt ist er trotzdem ein schlechter Programmierer.Und daran ändert sich auch nix wenn du bestimmte Dinge als "zu hoch gehängte Akademische Glocke" bezeichnest.
Die wenigsten unwartbaren Programme sind für den Benutzer gut. Vorausgesetzt das Programm wird lange genug "gewartet" (=über Monate oder Jahre hinweg immer wieder erweitert/geändert) ergibt sich irgendwann mal ein so verbuggter und inkonsistenter Dreckshaufen dass kein User gerne damit arbeiten mag. Also ist es IMO eine Voraussetzung halbwegs sauberen Code zu schreiben, wenn man ein gut bedienbares Programm haben will. Es ist aber eben auch nur eine Voraussetzung, und für sich genommen noch nicht ausreichend.
Und nachdem das Thema hier das Programmieren war, und nicht User-Interface-Design, würde ich mal sagen: deine Einwände sind völlig off-topic
-
hustbaer, du wiederholst dich
-
Xin schrieb:
Worum geht's? Man sagt der Templateklasse, von der man ableitet, wer man selbst ist. class B : public A<B>. Jemand dabei gewesen, der bei "Curiously Recurring Template Pattern" schon wusste, worum es ging?
Und wer weiß bei deiner Beschreibung worum es geht? Warum benutzt man das? Wobei ist das hilfreich? CRTP->erster Link auf Google. class B : public A<B>-> ???
-
otze schrieb:
Xin schrieb:
Worum geht's? Man sagt der Templateklasse, von der man ableitet, wer man selbst ist. class B : public A<B>. Jemand dabei gewesen, der bei "Curiously Recurring Template Pattern" schon wusste, worum es ging?
Und wer weiß bei deiner Beschreibung worum es geht? Warum benutzt man das? Wobei ist das hilfreich? CRTP->erster Link auf Google. class B : public A<B>-> ???
Falsche Fragestellung: Wer das Pattern kennt, aber nicht den Namen, wird in einer Diskussion nicht zwangsläufig Google fragen können. Diskussionen gibt es ja nicht nur in Internetforen, sondern auch von Angesicht zu Angesicht.
Es ging eben darum, dass man nicht alle Buzzwords kennen muss/kann... sollte?
Wenn Du mich morgen auf CRTP ansprichst, werde ich keine Ahnung, wovon Du sprichst. Das Pattern kenne ich trotzdem.
-
Xin schrieb:
Falsche Fragestellung: Wer das Pattern kennt, aber nicht den Namen, wird in einer Diskussion nicht zwangsläufig Google fragen können.
Doch sicher, wer in der Lage ist Google gut zu benutzen, wird diese Dokument finden (greade gegooglt): http://www.dre.vanderbilt.edu/~sutambe/documents/More C++ Idioms.pdf
-
Zeus schrieb:
Xin schrieb:
Falsche Fragestellung: Wer das Pattern kennt, aber nicht den Namen, wird in einer Diskussion nicht zwangsläufig Google fragen können.
Doch sicher, wer in der Lage ist Google gut zu benutzen, wird diese Dokument finden (greade gegooglt): http://www.dre.vanderbilt.edu/~sutambe/documents/More C++ Idioms.pdf
Zurück zum Niveau: Ich frage mich gerade, wie man eine Diskussion zielführend fortsetzen soll, bei der zwischenzeitlich das Ziel ausgetauscht wird. Das ist wie mit Navi fahren und auf halber Strecke es auf Heimatort umstellen und glücklich sein, dass man am Ziel angekommen ist.
Ich glaub' ich mach jetzt noch was sinnvolles...
Trotzdem, guter Link.
-
Xin schrieb:
Es ging eben darum, dass man nicht alle Buzzwords kennen muss/kann... sollte?
Wenn Du mich morgen auf CRTP ansprichst, werde ich keine Ahnung, wovon Du sprichst. Das Pattern kenne ich trotzdem.Doch, man muss sie kennen - sonst ist eine Diskussion nicht moeglich.
Pattern sind jetzt aber nicht was ich als Buzzword bezeichnen wuerde. Aber wenn bei uns eine Besprechung ist, dann muss jeder die Terminologie kennen. Das ist Grundvoraussetzung. Sonst dauern solche Besprechungen ewig. Wir schulen deswegen auch die nicht Techniker auf gewisse Vokabeln.
Das bedeutet natuerlich, dass man zeitweise Vokabeln lernen muss.
Fuer mich sind sowas die Grundlagen. Denn sonst ist Kommunikation nicht moeglich.
-
Shade Of Mine schrieb:
Xin schrieb:
Es ging eben darum, dass man nicht alle Buzzwords kennen muss/kann... sollte?
Wenn Du mich morgen auf CRTP ansprichst, werde ich keine Ahnung, wovon Du sprichst. Das Pattern kenne ich trotzdem.Doch, man muss sie kennen - sonst ist eine Diskussion nicht moeglich.
Das bedeutet natuerlich, dass man zeitweise Vokabeln lernen muss.
Fuer mich sind sowas die Grundlagen. Denn sonst ist Kommunikation nicht moeglich.
In diesem Paradigma wird dauerhaft keine hochqualifizierte Diskussion möglich sein. Und an dem Punkt sind wir ja schon lange vorbei.
Warum?
Davon auszugehen, dass jeder in einer unbekannten Runde - wie dieser - über die gleiche Terminologie verfügt, macht es einfach eine Diskussion zu unterbrechen und zu sagen "Du hast da was nicht verstanden", "Unfug" - es ist leicht einen Schuldigen zu bestimmen, der dann die Verantwortung tragen darf, dass eine Diskussion stockt. Ggfs. macht man einen Exkurs, um die Schuldfrage zu diskutieren, was sowieso gerne viel engagierter getan wird, als sich um den ursprünglich fraglichen Punkt zu kümmern.Was haben wir davon? Nix.
Wer sich für Neues interessiert, darf an solchen Diskussionen nicht qualifiziert teilnehmen und muss unterwürfig schlucken, was ihm dargeboten wird. So werden implizit Hierarchien geschaffen, die bekanntlich nicht dazu geeignet sind, das ein optimales Ergebnis zu erziehen, sondern dafür schnell zu Entscheidungen zu gelangen.
Es ist wie mit der Politik: Während die Demokratie eher träge ist, ist die Diktatur sehr wendig, erzieht aber nur punktuell herausragende Ergebnisse. Um eine Demokratie sinnvoll zu führen, muss der Bürger informiert sein, um sich einbringen zu können. Das ist er in der Regel nicht. Das bedeutet, dass der Idealfall eher die Ausnahme ist. Auf dem Weg zu optimalen Ergebnissen, muss man diese Tatsache erstmal so akzeptieren.
Dennoch können Bürger gute Ideen liefern. Die Grundannahme, das der Bürger informiert zu sein hat, ist also nicht zielführend für ein optimales Ergebnis.
Jede Annahme ist nur eine Fehlerquelle.Eine qualifizierte Unterhaltung muss also Pausen bieten, sich Sachverhalte, die nunmal nicht jeder kennen kann, freundlich zu erklären, bzw. zu benennen und Bekanntes in seiner Bedeutung abzugleichen. Das ist eine andere Form der Diskussionskultur. Die würde ich als Grundlage für eine qualifizierte Diskussion sehen, zumal es ein sich gegenseitig beschleunigender Effekt ist.
Menschliche Kommunikation ist sehr komprimiert, implizit und daher für detaillierte Sachverhalte eigentlich ungeeignet. Darum programmiert man auch in z.B. C und nicht in Englisch.Die Vorstellung, dass alle gefälligst mit den gleichen Grundlagen in eine Diskussion gehen, ist nicht nur illusorisch, es ist auch unproduktiv, denn wenn alle das identische Denk-Muster im Kopf haben, so besteht ja auch kein Grund zur Diskussion. Auch dieses Muster kennen wir aus dem Alltag in Form von "Das haben wir schon immer so gemacht".
Aber zum Thema Diskussionskultur kann ich mir hier eh den Mund fusslig reden. ^^
-
von "Vokabeln" auf identische Denkmuster zu kommen ist ein _so_ weiter Sprung, dass ich mich so langsam frage, welche Diskussion du gerad verfolgst.
Schnelles Gegenbeispiel: Bei uns ind er Arbeitsgruppe arbeiten alle mit derselben Kovnention wie man formeln aufschreibt, welche indizes was bedeuten etc. Und trotzdem machen alle völlig unterschiedliche Dinge, denken ganz anders und kommen zu unterschiedlichen Lösungswegen.
Am Ende verstehen aber alle die ANsätze der anderen, weil das Vokabular stimmt.
-
Ich kenne dies nur aus der Elektroniksprache aus der Lehrzeit, wenn wir da jeder für die Schaltung eines Schmidt-Trigger oder Monoflop was anderes gesagt hätten, aber dasselbe gemeint hätten, dann wäre dies schon sehr anstrengend für alle Beteiligten gewesen.
Bei der Softwarebranche kann ich nicht so mitreden, in der Zeit wo ich das beruflich gemacht habe, war ich absoluter Anfänger und habe aber gleich die Leitung für den Webbereich gehabt. War etwas schwierig, aber wir haben mit etwas Verzögerung alles hin bekommen und es läuft heute immer noch. OOP war da noch ein Fremdwort in PHP und dementsprechend wurde nur von Funktionen/Schnittstellen oder fertigen Modulen geredet.
-
Xin schrieb:
Die Vorstellung, dass alle gefälligst mit den gleichen Grundlagen in eine Diskussion gehen, ist nicht nur illusorisch, es ist auch unproduktiv, denn wenn alle das identische Denk-Muster im Kopf haben, so besteht ja auch kein Grund zur Diskussion. Auch dieses Muster kennen wir aus dem Alltag in Form von "Das haben wir schon immer so gemacht".
Vokabeln sind Vokabeln und haben nichts mit Denk Mustern zu tun.
Die gleichen Vokabeln zu verwenden ist die Grundlage jeder Kommunikation.
