Bezeichnungen in deutsch oder englisch?
-
this->that schrieb:
+1 für die Leute, die Deutsch in sinnvollen Fällen benutzen.
Eine Faustregel wie IMMER Englisch ist sinnfrei.Und ich halte es für kurzsichtige Kleinstaaterei. Argumentation siehe Draveres Beiträge. "Nein, unsere Software wird für alle Zeiten nur von Programmierern angesehen werden die Deutsch als Muttersprache haben. Wir werden sie niemals exportieren, niemals mit anderer Software kombinieren und niemals ausländische Programmierer einstellen". Das ist vielleicht bei einem privaten Hobbyprojekt noch realistisch aber sonst nicht.
Das Argument, dass es keine englischen Begriffe gäbe kann ich auch nicht gelten lassen. Wie unterhalten sich denn deutsche Bankkaufleute mit ausländischen Kollegen?
-
Da ich gerade Ferien habe kann ich ja mal auch noch meinen Senf dazugeben: ^^
Ich finde, dass man grundsätzlich Englisch verwenden sollte. Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.
Der einzige Ort an dem aus meiner Sicht Deutsch sinnvoll sein kann ist in einem Deutschen Tutorial für Anfänger. Da kann es vielleicht von Vorteil sein, da es leicht ersichtlich ist für Anfänger welche Teile des Programms selber gemacht sind und welche von irgendwo sonst herkommen. (Ging zumindest mir teilweise so).
Aber sonst aus meiner Sicht IMMER Englisch verwenden. (Ich hatte gerade eine Vorlesung in diesem Semester, in der z.B. Subscriber zu Subskribent oder Publisher zu Herausgeber wurde ==> äusserst mühsam).
-
icarus2 schrieb:
(Ich hatte gerade eine Vorlesung in diesem Semester, in der z.B. Subscriber zu Subskribent oder Publisher zu Herausgeber wurde ==> äusserst mühsam).
Das Beispiel ist ziemlich sinnfrei, denn das ist ja genau da, wo man sich auf Bibliotheksebene bewegt... da tut das keinem Weh, was die Entwickler so anstellen.
-
icarus2 schrieb:
Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.
Es verstehen auch nicht alle Englisch. Sie glauben es zwar, aber...
Noch besser wäre es ja mit einer französischen Firma zusammen zu arbeiten, und dann aus Gründen der Verständlichkeit alle Begriffe auf Englisch zu formulieren.
-
SeppJ schrieb:
Das Argument, dass es keine englischen Begriffe gäbe kann ich auch nicht gelten lassen. Wie unterhalten sich denn deutsche Bankkaufleute mit ausländischen Kollegen?
Es gibt nicht übersetzbare deutsche Fachterminologie, genauso wie im Deutschen englische Begriffe verwendet werden, weil wir keine eigenen entwickelt haben. Die Bereiche kann man sicherlich an einer Hand abzählen, aber es ist so. Der Bahnbereich ist ein gutes Beispiel. Bahn funktioniert in England, Frankreich, Deutschland und Amerika eben anders. Und im Rest der Welt so, wie in einem der Vorgenannten.
-
SeppJ schrieb:
Und ich halte es für kurzsichtige Kleinstaaterei. Argumentation siehe Draveres Beiträge. "Nein, unsere Software wird für alle Zeiten nur von Programmierern angesehen werden die Deutsch als Muttersprache haben. Wir werden sie niemals exportieren, niemals mit anderer Software kombinieren und niemals ausländische Programmierer einstellen".
Nochmal, solange dadurch der heute verkaufbare Wert des Produkts nicht erhöht wird - dieses Feature also nicht wertschöpfend ist - macht es keinen Sinn dafür Geld aufzuwenden. Wenn die berühmte User-Domain bereits englischsprachig ist, dann hat man Glück, und es fällt leicht alle Begriffe entsprechend zu behandeln. Aber wenn dem nicht der Fall ist muß man das bewerten - Argumentation in meiner Antwort an Dravere.
Aber für den Automatismus "es ist eleganter und könnte mal mehr Geld bringen" würde ich kein Geld spendieren.
-
Marc++us schrieb:
icarus2 schrieb:
Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.
Es verstehen auch nicht alle Englisch. Sie glauben es zwar, aber...
Dann sind sie eben nicht qualifiziert, um gute Software zu entwickeln. Das ist dann genauso wie ein Programmierer der durch andere Stilfehler schlecht wartbaren Code schreibt. Da besteht meines erachtens nach kein großer Unterschied zwischen jemandem der Spagetthiode schreibt und jemandem der deutsche Bezeichner benutzt. Den Spagetticode kann dann nur ein Genie durchschauen, den deutschen Code nur jemand der Deutsch spricht. Der Unterschied ist bloß die unterschiedliche Anzahl von Deutschsprechern und Genies auf der Welt. Letztlich ist beides für große Teile der Weltbevölkerung unverständlich.
Gegenfrage: Wären Bezeichner auf chinesisch ok? Oder was ist wenn wir eine noch seltenere Sprache als Deutsch sprechen würden, z.B. baskisch. Ist es für einen baskischen Programmierer ok, baskische Bezeichner zu benutzen?
-
SeppJ schrieb:
Marc++us schrieb:
icarus2 schrieb:
Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.
Es verstehen auch nicht alle Englisch. Sie glauben es zwar, aber...
Dann sind sie eben nicht qualifiziert, um gute Software zu entwickeln. Das ist dann genauso wie ein Programmierer der durch andere Stilfehler schlecht wartbaren Code schreibt. Da besteht meines erachtens nach kein großer Unterschied zwischen jemandem der Spagetthiode schreibt und jemandem der deutsche Bezeichner benutzt. Den Spagetticode kann dann nur ein Genie durchschauen, den deutschen Code nur jemand der Deutsch spricht. Der Unterschied ist bloß die unterschiedliche Anzahl von Deutschsprechern und Genies auf der Welt. Letztlich ist beides für große Teile der Weltbevölkerung unverständlich.
Gegenfrage: Wären Bezeichner auf chinesisch ok? Oder was ist wenn wir eine noch seltenere Sprache als Deutsch sprechen würden, z.B. baskisch. Ist es für einen baskischen Programmierer ok, baskische Bezeichner zu benutzen?
zieh dir doch mal php sourcecode rein, die erlauben ja unicode in bezeichnern. ich hab mich da gelegentlich schon ganz schön geärgert...
-
SeppJ schrieb:
Das Argument, dass es keine englischen Begriffe gäbe kann ich auch nicht gelten lassen. Wie unterhalten sich denn deutsche Bankkaufleute mit ausländischen Kollegen?
Wenn englische Banker (auch untereinander) über Pfandbriefe sprechen, reden sie von "pfandbriefs" oder "german pfandbriefs". Umgekehrt sprechen deutsche Banker von Gilt-Bonds oder auch einfach Gilts. Deutscher als "Gilt-Anleihe" wird's jedenfalls nicht. Das amerikanische Finanzministerium wird idR auch von deutschen Bankern schlicht als "US-Treasury" bezeichnet, und die Bundesbank wird auch in Amerika "German Bundesbank" genannt.
Die stehen nämlich vor genau dem selben Problem, und der Praktiker benutzt einfach den Namen weiter, den es schon gibt. Dass der nicht in der eigenen Landessprache ist, ist von untergeordneter Bedeutung.
-
SeppJ schrieb:
this->that schrieb:
+1 für die Leute, die Deutsch in sinnvollen Fällen benutzen.
Eine Faustregel wie IMMER Englisch ist sinnfrei.Und ich halte es für kurzsichtige Kleinstaaterei. Argumentation siehe Draveres Beiträge. "Nein, unsere Software wird für alle Zeiten nur von Programmierern angesehen werden die Deutsch als Muttersprache haben. Wir werden sie niemals exportieren, niemals mit anderer Software kombinieren und niemals ausländische Programmierer einstellen". Das ist vielleicht bei einem privaten Hobbyprojekt noch realistisch aber sonst nicht.
Das Argument, dass es keine englischen Begriffe gäbe kann ich auch nicht gelten lassen. Wie unterhalten sich denn deutsche Bankkaufleute mit ausländischen Kollegen?
-
this->that schrieb:
seldon hat doch gerade gesagt, wie die sich mit mit Engländern unterhalten. Wenn die Übersetzung von Pfandbrief eben pfandbrief ist, dann ist das etwas was man im Programm benutzen kann. Nur weil das dann im Englischen ein Lehnwort ist, ist es immer noch Englisch.
-
Ob man nicht übersetzbare Begriffe deutsch belässt oder sie mit ihrem identischen Lehnwort übersetzt, ist doch Erbsenzählerei.
-
Marc++us schrieb:
Nochmal, solange dadurch der heute verkaufbare Wert des Produkts nicht erhöht wird - dieses Feature also nicht wertschöpfend ist - macht es keinen Sinn dafür Geld aufzuwenden.
Das halte ich für ein typisches kurzsichtiges Managerdenken. Wenn man nicht auf dem Papier nachweisen kann, dass etwas sofort Gewinn abwirft, dann wird kein Geld investiert. Völliger Habakuk...
Es gibt zahlreiche Features, welche den heutigen verkaufbaren Wert nicht sofort erhöhen, aber dafür in der Zukunft riesen Summen einsparen können.
Dieses kurzsichtige Denken ist genau wie in der Politik mit Bauten umgegangen wird. Da wird mit heutigen Kapazitäten geplant und wenn dann in 10 Jahren die Verkehrsachse besteht, muss sie bereits wieder abgerissen und neugebaut werden. Wenn man dagegen vorausgeplant und ein wenig vorausgedacht hätte, hätte man riesige Summen einsparen können. Aber es hatte damals zu diesem Zeitpunkt halt keinen Mehrwert, also wird es ignoriert...Vorausdenken muss nicht PMO sein, sondern kann auch eine Risikoreduktion bedeuten, wofür es sich lohnen kann, Zeit/Geld zu investieren. Die Wertschöpfung muss nicht heute/morgen/übermorgen passieren, sondern kann auch erst in 5 Jahren auftauchen.
Klar, das heisst natürlich auch nicht, dass man es übertreiben muss. Ich habe es ja auch als Richtlinie gemeint. Aber halt ein wenig menschliches und vernünftiges Denken reinbringen, schadet sicher nicht, anstatt immer sturr nach irgendwelchen irreellen Zahlen zu rechnen. Wahrscheinlich nach Model XYZ, wobei eine Wertschöpfung auf 6 Nachkommastellen genau rauskommt, welche bereits nach einem Monat hinten und vorne nicht mehr stimmt.
Wozu sollen die Mitarbeiter glücklich sein? Der Automat darf keine gratis Snacks verteilen, das hat keinen Mehrwert für das Produkt. Eigene Büros? Kostet zuviel! Streichen wir alles, braucht es nicht, dafür haben wir nun auf dem Papier ein fettes Plus. Wir sind gut und schnappen uns den Bonus. Was in 5 bis 10 Jahren ist, obwohl gerade Software eigentlich sehr langlebig ist, kümmert uns einen alten Hut.
Die DB wird es dir auch danken, wenn deine Firma kaputt geht und die Software von einer anderen Firma (womöglich ausländischen?), übernommen und weitergewartet wird. Das könnte sogar noch zu einem Verkaufsargument werden, schliesslich geht die DB ein höheres Risiko ein, wenn die Software nur von deutschen Entwicklern gewartet werden kann.
... der Beitrag ist gerade ein wenig ein durcheinander, aber ich habe keine Lust mehr aufzuräumen. Dieser Satz, den ich in so manchen Formen nun schon gehört habe, ärgert mich einfach nur. Man hätte so viel Geld einsparen und so viele Probleme frühzeitig lösen können, wenn die Manager nicht nur auf das Papier geschaut hätten. Aber nein, man gibt lieber heute weniger aus, damit man dann morgen das 10-fache ausgeben kann, damit auch ja die aktuelle Bilanz schön aussieht.
Grüssli
-
Dravere schrieb:
Vorausdenken muss nicht PMO sein, sondern kann auch eine Risikoreduktion bedeuten, wofür es sich lohnen kann, Zeit/Geld zu investieren. Die Wertschöpfung muss nicht heute/morgen/übermorgen passieren, sondern kann auch erst in 5 Jahren auftauchen.
"Vorausdenken" kann das Risiko verringern, allerdings genau so auch erhöhen. Das Risiko dass ein Projekt den Bach runter geht, ist bei einem Projekt das mehr kostet, länger dauert und schwieriger zu entwickeln ist einfach höher.
Man muss - wie überall - die Vorteile gegen die Nachteile aufwiegen.
Da es glaube ich keine brauchbaren Zahlen zu dem Thema gibt, ist das natürlich nicht einfach, bzw. eine sehr subjektive Sache.Zu viele Dinge vorauszuplanen kann die Entwicklungszeit enorm verlängern, und das kann schnell mal das Aus für eine Firma bedeuten - ganz speziell Startups. Die Erfahrung zeigt auch recht deutlich, dass man heute schwer abschätzen kann, was man morgen brauchen wird, bzw. was Feature X morgen an Wert für die Firma bedeuten wird.
-
...... schrieb:
Ob man nicht übersetzbare Begriffe deutsch belässt oder sie mit ihrem identischen Lehnwort übersetzt, ist doch Erbsenzählerei.
Aber es passt zur Weihnacht
rucke di guck, rucke di gu ...;)
-
Marc++us schrieb:
Nochmal, solange dadurch der heute verkaufbare Wert des Produkts nicht erhöht wird - dieses Feature also nicht wertschöpfend ist - macht es keinen Sinn dafür Geld aufzuwenden.
Und darum wurden bei uns immer nur neue Features eingebaut, aber nie was refactored und jetzt ist die SW Müll und muss neu geschreiben werden.
-
Ich benutze selbstverständlich deutsch, weil mein Code weder internationl rumgereicht wird, noch weil ich Wert darauf lege meine Freunde beeindrucken zu wollen
Nebeneffekt von deutschen Bezeichnungen: man kann sie ganz eindeutig als eigene erkennen, statt sie mit vorgegebenen Namen zu verwechseln.
Die Empfehlungen für Englisch lassen praktisch immer ausser Acht, dass es sich bei 99% der Leute hier nicht um festangestellte Profiprogrammierer handelt, welche in internationalen Arbeitsgruppen tätig sind
Ich brings mal auf den Punkt: wer nicht international tätig ist, seine Kinder aber Justin, Cindy etc nennt, der nimmt natürlich englisch als Code-Begleitsprache, alles klar?
-
Die Empfehlungen für Englisch lassen praktisch immer ausser Acht, dass es sich bei 99% der Leute hier nicht um festangestellte Profiprogrammierer handelt, welche in internationalen Arbeitsgruppen tätig sind
Du wirst es nicht glauben, aber es gibt auch Deutsche, die die englische Sprache ausreichend gut beherrschen um trotzdem den Quellcode problemlos verstehen zu können. Ich würde sogar behaupten besser, da man weniger zwischen den Sprachen wechseln muss (englische Sprachkonstrukte und deutsche Bezeichner).
Ich arbeite auch nicht als Programmierer und verwende trotzdem englische Bezeichner, weil ich damit einfach besser zurecht komme. Alle Bücher, die ich zur Informatik lese, sind in Englisch verfasst, alle Online-Referenzen auch, etc..
Da fällt es mir einfach leichter auch englische Bezeichner zu verwenden. Auch muss man da nicht die Sonderzeichen (ßäöü) im Deutschen beachten.Nebeneffekt von deutschen Bezeichnungen: man kann sie ganz eindeutig als eigene erkennen, statt sie mit vorgegebenen Namen zu verwechseln.
Scheinargument... Ist dir das wirklich schonmal passiert?
-
hustbaer schrieb:
Zu viele Dinge vorauszuplanen kann die Entwicklungszeit enorm verlängern, und das kann schnell mal das Aus für eine Firma bedeuten - ganz speziell Startups. Die Erfahrung zeigt auch recht deutlich, dass man heute schwer abschätzen kann, was man morgen brauchen wird, bzw. was Feature X morgen an Wert für die Firma bedeuten wird.
Vorausplanen heisst nicht Feature X umsetzen, sondern Türen offen lassen, damit Feature X mal umgesetzt werden könnte.
Das Produkt in Englisch zu entwickeln lässt viele wichtige Türen offen und der Mehraufwand hält sich meiner Meinung nach sehr in Grenzen.Schauen wir uns doch nur mal die aktuellen Prognosen für den Informatikermarkt an. In 7 Jahren sollen in der Schweiz 40'000 Informatiker fehlen. Sicherlich sind davon eher weniger Coder, aber die machen auch einen Anteil daran aus. Individualsoftware hat eine Lebensdauer von 10-20 Jahren. Da kann ja wohl niemand davon ausgehen, dass man diese Software ausschliesslich mit deutsprachigen Informatikern am Leben erhalten kann.
Abgesehen davon gibt Englisch dem Code eine Konsistenz. Ein Mischmasch führt zu Verwirrungen und der englische Anteil wird dann erst recht falsch verstanden. Ein Teil des Codes wird immer in Englisch sein, daran führt kein Weg vorbei. Wartbarkeit ist bei Software mit 10-20 Jahren Lebensdauer wohl das A und O. Damit Startups nicht nur den Startup überleben.
Grüssli
