Programmieren allgemein - warum so Alltagsfremd und mehrdeutig?

Man kann sich auch anstellen.

Cleve schrieb:
> Muss man sein Gehirn (als Erwachsener) erstmal umprogrammieren und
> Programmieren zu verstehen?

Ja.

Cleve schrieb:
> Muss man sein Gehirn (als Erwachsener) erstmal umprogrammieren und
> Programmieren zu verstehen?

Nö. Mann muss sich nur mal vernünftige Literatur besorgen, z.B. für C 
den K&R auf Englisch. Englisch deshalb weil 99,9% der sonstigen 
Literatur (Datenblätter etc.) nur englisch verfügbar ist und man so die 
korrekten Fachbegriffe gleich mit lernt.

Fachspezifische Texte sind ohne Kenntnis der Fachbegriffe für Laien 
nicht lesebar - das gilt aber nicht nur für die Programmierung sondern 
praktisch immer. Wegen der extremen Dominanz des Englischen sind 
deutsche Übersetzungen im Bereich Programmierung z.T. deutlich 
schwieriger zu lesen - und oftmals auch fehlerhaft.


Man braucht auch einen soliden mathematischen Hintergrund. Wieso Dir das 
Konzept einer Funktion aus dem Mathematikunterricht nicht bekannt sein 
soll ist mir unklar. Die C Funktionen sind eine (echte) Teilmege der 
Funktionen aus der Mathematik - man schreibt die nur halt 
maschinenlesbar (C-Compiler) auf.

Ohne solides mathematisches Wissen hat man in der Programmierung nix 
verloren IMHO.

Cleve schrieb:
> Warum wird z.B. der so mannigfaltig belegte Begriff "Funktion" bei der
> Sprache C verwendet?

Irgendeinen Namen muss man dem Kind ja geben. Entweder man nimmt einen
bereits bestehenden Begriff, der eine ähnliche Bedeutung wie das zu
benennende Ding hat, oder man denkt sich ein neues Wort aus.

Wäre es dir lieber, wenn die C-Funktionen "Hulobilu" hießen? Dieser
Begriff hat m.W. keine andere Bedeutung, wäre also eindeutig.

In den meisten Fachsprachen (nicht nur in der Computerei, sondern bspw.
auch im Ingenieurswesen, in den Naturwissenschaften und in der
Mathematik) werden aber bestehende Begriffe in einer abgewandelten
Bedeutung benutzt, da diese i.Allg. leichter zu merken sind als
Wortneuschöpfungen.

Wie oben schon geschrieben wurde, wurde der Begriff "Funktion" in C aus
der Mathematik übernommen, wo eine Funktion abhängig von einer Anzahl
von Argumenten einen Ergebniswert liefert. Genau dieses trifft auch für
C-Funktionen zu. In einigen anderen Eigenschaften unterscheiden sich C-
von mathematischen Funktionen zwar, trotzdem kann ich mir in diesem
Zusammenhang den Begriff "Funktion" besser merken als "Hulobilu".

Darf ich Fragen, welchen Beruf du ausübst? Wenn du mal genauer darüber
nachdenkst, wirst du feststellen, dass du dort ebenfalls jede Menge
mehrdeutiger Begriffe verwendest, die für einen Laien nicht sofort
verständlich sind.

Christian M. schrieb:
> PS: Danke schonmal für die Negativbewertungen!

Bitte schön, gern geschehen!

Georg schrieb:
> Ein Programm ist es
> nicht: der Computer tut GANZ GENAU das, was da steht. Möglicherweise ist
> es nicht das, was du vorhattest, aber das liegt weder am Computer noch
> an der Programmiersprache, sondern an der mangelnden Qualifikation des
> Programmschreibers.

Nein. Es hängt in hohem Maße vom Compiler ab, was aus einem 
C-Quelltext für ein Programmcode generiert wird.
Das Resultat kannst Du an den jeden Tag dazu eingehenden Beiträgen 
sehen, in denen solche Probleme geschildert werden.

@Christian Müller
Das ist ganz exakt von Dir beschrieben.

-Feldkurat-

Feldkurat K. schrieb:
> Nein. Es hängt in hohem Maße vom Compiler ab, was aus einem
> C-Quelltext für ein Programmcode generiert wird.
> Das Resultat kannst Du an den jeden Tag dazu eingehenden Beiträgen
> sehen, in denen solche Probleme geschildert werden.

Und bei den meisten Problemen ist es dann doch wieder der Wasserkopf 
vorm Monitor. Bugs gibt es natürlich, aber gerade Anfänger machen es 
sich gerne leicht, alles was an ihrem Wundercode nicht geht, darauf zu 
schieben.

Georg A. schrieb:
> Und bei den meisten Problemen ist es dann doch wieder der Wasserkopf
> vorm Monitor.

Unbestritten.
Das meinte ich aber nicht, sondern, daß aus ein und demselben 
C-Quelltext von verschiedenen Compilern auf verschiedenen Rechnern unter 
verschiedenen Betriebssystemen unterschiedliche Resultate entstehen. 
Dann beginnt die Debatte darüber, ob der jeweilige Ausdruck unter 
dieser Bedingung zulässig ist oder nicht. Das nützt dem Fragesteller 
aber nicht.

-Feldkurat-

Cleve schrieb:
> Je nach Programmiersprache versucht man ja mehr oder weniger nah an die
> "normale" im, englischsprachigen, Alltag gesprochen Sprache an zu
> knüpfen.

Einige Programmiersprachen versuchen das, andere nicht.

Cleve schrieb:
> Liegt das das die Programmierliteratur immer nur von (sorry ist nicht
> böse gemeint) Fachidioten geschrieben wird, das man sich abgrenzen will,
> das man zu sehr im (mühsam an trainierten) "Programmiersprech"
> verwurzelt ist oder...?

Wie kommst du auf die Idee, dass eine Programmiersprache für die 
Allgemeinheit verständlich sein muss? Sie soll ihren Zweck erfüllen und 
nicht schön aussehen.

Im IT-Bereich fühlt sich komischerweise jeder als Profi, will aber 
nichts dazu lernen und beschwert sich dann noch über die echten Profis. 
Das gibt es in anderen Berufen nirgendwo so extrem. Geh mal zum Arzt und 
sag ihm: "Warum müssen alle medizinischen Begriffe auf Latein sein?" 
Oder zum Mechaniker: "Warum muss das Getriebe heißen und nicht 'viele 
Zahnräder'?"
"Nein Chef. Ich kann nur MS Office und kann deswegen kein LibreOffice 
benutzen. Kauf mir das gefälligst!"
"Nein Chef. Ich hab meinen Führerschein in einem Mercedes gemacht und 
kann deswegen keinen VW fahren. Kauf mir das gefälligst!"
...
Außerhalb der IT sagt der Chef einfach: GTFO!

Cleve schrieb:
> Muss man sein Gehirn (als Erwachsener) erstmal umprogrammieren und
> Programmieren zu verstehen?
Mag eine Ausnahme sein, aber ich musste da nie groß umdenken. Erst die 
"wirklichkeitsnähere" OOP machte da größere Probleme.

Dussel schrieb:
> Cleve schrieb:
>> Je nach Programmiersprache versucht man ja mehr oder weniger nah an die
>> "normale" im, englischsprachigen, Alltag gesprochen Sprache an zu
>> knüpfen.
> Im Allgemeinen Nein. Man benutzt nur für manche Anweisungen englische
> Wörter, weil das am naheliegendsten ist.
>
> Cleve schrieb:
>> Warum wird z.B. der so mannigfaltig belegte Begriff "Funktion" bei der
>> Sprache C verwendet?
>>
>> Den gibt es in der Mathematik
> Genau deshalb, wie mh schrieb.

Nun ja, die amerikanische Vokabel "function" beinhaltet weit mehr als 
das deutsche Wort "Funktion" und passt meiner Meinung nach auch deutlich 
besser zu dem, was da beschrieben wird. Hier geht bei der Übersetzung 
einiges verloren.

>
> Welche Begriffe sollten denn sonst verwendet werden?
>
> Cleve schrieb:
>> Klasse = Schulklasse,
Ähnliches Thema, "class" beinhaltet einiges mehr als nur die 
Schulklasse. Vielleicht wäre "Gruppe" die richtigere Übersetzung 
gewesen.

>> Biliothek = Bücher und Filme ausleihen...
"Library" kann was ganz anderes sein als eine Bücherei. In dem Fall ist 
es wohl eher eine Sammlung.

Insgesammt hat man beim Eindeutschen ziemlich geschlampt, was dazu 
führt, dass die Begriffe nicht mehr so wirklich zu dem passen, was sie 
eigentlich beschreiben sollten.

Gruss
Axel

Feldkurat K. schrieb:
> Das meinte ich aber nicht, sondern, daß aus ein und demselben
> C-Quelltext von verschiedenen Compilern auf verschiedenen Rechnern unter
> verschiedenen Betriebssystemen unterschiedliche Resultate entstehen.
> Dann beginnt die Debatte darüber, ob der jeweilige Ausdruck unter
> dieser Bedingung zulässig ist oder nicht. Das nützt dem Fragesteller
> aber nicht.

Ist das wirklich hier im Forum so häufig? Da habe ich nicht den 
Eindruck, Gibt evtl. ein paar pathologische Fälle abseits expliziter 
"undefined"-Regeln, aber das ist eher so Nerdtalk...

Ist das wirklich hier im Forum so häufig?

Ja, ist es. Nur ein Beispiel aus der letzten Zeit:

Beitrag "C-Programmierung - Vergleich"



K. L. schrieb:
> Wie kommst du auf die Idee, dass eine Programmiersprache für die
> Allgemeinheit verständlich sein muss? Sie soll ihren Zweck erfüllen und
> nicht schön aussehen.

Kommst Du nicht auf die Idee, daß eine Sprache immer erst erlernt 
werden muss und daß das um so einfacher geht, je verständlicher die 
Syntax ist?
Die Sprachen werden von Jahr zu Jahr komplizierter und ihre Zahl wächst 
und wächst -ohne Not!

-Feldkurat-

Englisch ist die Sprache der Software weil die Technologie von dakommt. 
Wir hatten Glueck und diese Sprache ist mit der unseren stark verwandt. 
Vom Schriftsatz, wie auch von der Mentalitaet her.
Waere Russisch, Arabisch, Farsi, Japanisch, Chinesisch besser gewesen ? 
Nachdem du die Schrift Zeichen gelernt haettest, und den Aufbau der 
normalen Sprache, wohlgemerkt...

Und sei froh, bist du nicht Franzose. Die muessen erst alles 
Ein-franzoesischen, mit dem Nachteil, dann sie niemanden mehr fragen 
koennen, weil die den franzoesischen Ausdruck eh nicht kennen.

Cleve schrieb:
> Je nach Programmiersprache versucht man ja mehr oder weniger nah an die
> "normale" im, englischsprachigen, Alltag gesprochen Sprache an zu
> knüpfen.

Gegenfrage: schonmal versucht, ein  Problem mit - sagen wir drei 
Variablen absolut exakt in allen Einzelheiten in einer natürlichen 
Sprache zu beschreiben, und zwar ohne gedankenbrüche wie dieser 
Nebensatz hier?


Deshalb braucht es Programmiersprachen. Sie helfen, die logik, 
anweisungen  und Formeln in Konstrukte zu verwandeln, die eine CPU 
versehen kann.

Ob das einfach Mnemonics in Assembler sind, die 1:1 in Maschinenbefehle 
übersetzt werden oder "For (i=10;i==0;i--) {}" die je nach CPU in sowas 
einfaches wie

loop:
...
DJNZ lopp;

übersetzt werden.

Daneben kannst du als Programmieraufgabe in natürlicher Sprache 
folgendes fordern: "Ich habe hier eine gegebene Word-Datei. Wie schwer 
wird später das gedruckte Buch sein?". Eine scheinbar leichte aufgabe, 
wenn man denn wüsste, welche Daten denn alle dabei noch fehlen 
(Papierdichte, Buchart etc...).

Viele englische Wörter haben weniger Buchstaben als deutsche Wörter, 
passen daher besser in den Programmtext.


Ich hatte übrigens enorme Schwierigkeiten mit meinem allerersten 
C-Programm! Ich habe mir am Ende die Beispiel-WinMain ausgedruckt und 
sogar mit aufs Klo genommen. Irgendwann sprang der Funke über und ich 
erkannte das Notations-Prinzip: also links der Typ, dann der Name und 
dann die Übergabeparameter.


Ich programmiere gerade in Assembler und es zeichnen sich wiederholende 
Muster ab. Man muss dauernd etwas subtrahieren und auf "=0" testen wenn 
es gleich sein soll und muss dann bedingt springen. Und man muss sehr 
schlau sein wenn man zB. aus einer Cursorposition einen Platz im 
Speicher oder gar nur das Nibble errechnen muss. Bisher kam mir immer 
der rettende Einfall bzw. die Formel  :-)

Edit: Auch scheint es dass man sich Programm-"Blöcke" machen muss die 
man dann bedingt-direkt anspringen kann, da ja die bedingten Sprünge 
meist nur kurze Reichweiten haben. Das ganze endet dann oft in einer 
großen Schleife wo im Kopf eine Aktualisierung stattfindet mit den 
Werten die weiter unten verändert wurden.


Cleve schrieb:
> Muss man sein Gehirn (als Erwachsener) erstmal umprogrammieren und
> Programmieren zu verstehen?
Manche Aufgaben beim Programmieren sind wirklich abstrakt! Da muss man 
räumlich/geometrisch, mathematisch, logisch usw. gleichzeitig denken. 
Ich erinnere mich da an einen "Pinsel" in einem C-Programm für einen 
Terrain/Höhen-Editor. Das war ein Kreis den man über das Gelände bewegen 
konnte zum Anheben und Absenken der Landschaft aus Dreiecken. Ich weiss 
es nicht mehr genau aber ich habe es geschafft damals so eine Funktion 
zu programmieren.

Cleve schrieb:
> Je nach Programmiersprache versucht man ja mehr oder weniger nah an die
> "normale" im, englischsprachigen, Alltag gesprochen Sprache an zu
> knüpfen.

Ach?

http://archive.vector.org.uk/content/printed/251/saigusa/image009.jpg

Cleve schrieb:
> Verdammt nochmal: Warum diese, zwar richtigen, aber für den Einsteiger
> sehr verwirrende Begrifflichkeiten dann noch garniert mit 1001
> Sonderzeichen die "Nichtprogrammierer" nie verwendet,

Um das Programm kompakt genug zu gestalten, dass man nicht den Wald vor 
lauter Bäumen aus dem Blickfeld verliert, wie es beim Geschwafel von 
COBOL leicht passieren kann (*).

> warum teilweise
> absolut Lebensfremde Bezeichnungen und Begrifflichkeiten wie
> Zustandsmaschine, inkrementieren, prozedural und und und...

Liegt vielleicht daran, dass es nicht für alle lebensfremd ist. Schöpfer 
von Programmiersprachen entstammen meist dem mathematisch/technischen 
Bereich. Die sind mit mathematischer Symbolik bereits vertraut.

Die krasseste Form der Umsetzung mathematischer Notation hatte ich 
soeben mit APL gezeigt. Das war übrigens meine erste Programmiersprache, 
selbst erlernt in der Oberstufe des Gymnasiums.

> Muss man sein Gehirn (als Erwachsener) erstmal umprogrammieren und
> Programmieren zu verstehen?

Das nennt man "lernen".

*: Massgeblich von Grace Hopper geschaffen. Eine der wenigen Frauen der 
Branche.

Feldkurat K. schrieb:
> Ja, ist es. Nur ein Beispiel aus der letzten Zeit:
>
> Beitrag "C-Programmierung - Vergleich"

Ich kann da nicht erkennen, dass es da um die nichtvorhersehbare 
Code-Erzeugung unterschiedlicher Compiler geht. Das ist eher eine 
Diskussion über sinnvolle Datenstrukturen und Ablageorte samt tauglicher 
Namen von Variablen. Sowas mag auch verwirren, aber so ist das halt bei 
professionellen Gerätschaften. Die haben viele Stellschrauben und 
Möglichkeiten und deswegen auch empfohlene Workflows...

Ich glaube aber, dass die Syntax nur ein Nebenkriegsschauplatz ist, das 
eigentliche Problem ist die (Un)Fähigkeit zum Erkennen von Strukturen 
und der Analyse/Zerlegung der Problemstellung. An der Uni musste/durfte 
ich viele Info-Erstsemester betreuen, da bekommt man das ganz gut mit. 
Manche Leute schaffen es nicht, Arbeitsabläufe sukkzessive in 
aufeinander aufbauende und immer weiter verfeinerte Schritte zu 
zerlegen. Die meinen irgendwie, dass sie den "Problemklotz" auf einmal 
zerquetschen müssten statt in kleinen Häppchen anzuknabbern...

Andy P. schrieb:
> loop:
> ...
> DJNZ lopp;

ERROR Label not defined

Georg A. schrieb:
> Manche Leute schaffen es nicht, Arbeitsabläufe sukkzessive in
> aufeinander aufbauende und immer weiter verfeinerte Schritte zu
> zerlegen.

Yep. Und sind auch nicht in der Lage, vorgegebene Arbeitsabläufe 
systematisch der Reihe nach auszuführen. Mein Eindruck ist, dass diese 
Leute solche Anweisungen nicht sequenziell betrachten, sondern das 
Gesamtbild wahrnehmen und ganzheitlich zu interpretieren suchen. Und 
darin dann ggf. Teile rauspicken, aber nicht von oben runter, sondern 
irgendwo anfangend. Ziemlich andere Denkweise.

Christian M. schrieb:
>> dann noch garniert mit 1001
>> Sonderzeichen

In C sind nur Zeichen aus dem ASCII Zeichensatz ( 7 Bit - 128 Zeichen) 
erlaubt. Wo sollen da 1001 Sonderzeichen herkommen?

>
> DAS ist ja nun wirklich nicht mehr nötig heute.

Es ist vielleicht nicht nötig, aber sehr sinnvoll, zur Strukturierung 
keine großen Worte zu machen, sondern Zeichen zu verwenden. Ein 
Quelltext soll ja kein Roman sein. Und selbst in Romanen gibt es 
Satzzeichen zur Strukturierung, die sich nicht so leicht durch Worte 
ersetzen lassen hieristderSatzzuende

JetzteinneuerAbsatz Ein '{' ist deutlicher und sowohl vom Programmierer 
als auch Compiler schneller zu lesen als ein Wort wie 
HierfängteinneuerBlockan. Die Möglichkeit von Tippfehlern steigt mehr 
als linear mit der Anzahl der Zeichen eines Wortes. Buchstaben gibt es 
immer noch genug zu lesen und zu schreiben in Schlüsselwörtern, Namen 
und Kommentaren Satzende Absatzende


> Aber weil sich C und
> Konsorten stur in einigen Köpfen und dem Mainstream festgesetzt hat,
> hält sich das hartnäckig. Das war vor Jahrzehnten(!) so gemacht worden
> um 1. wenig Speicher zu belegen, und 2. absichtlich schwierig zu sein.

Es war vor Jahrzehnten so gemacht worden und hat sich nun jahrzehntelang 
bewährt. 1.Die Speicherbelegung hängt nicht von der Form des Quelltextes 
ab. 2. Es ist absichtlich und dauerhaft einfacher, wenn man mal ein paar 
Minuten investiert, um die Bedeutung der Zeichen zu lernen.

Aber wem das nicht behagt, für den ist C so flexibel, dass es auch an 
solche absurden Wünsche angepasst werden kann.

#define HierfaengteinneuerBlockan {
#define HierhoertderletzteBlockauf }
#define EndederAnweisung ;
#define Zaehledazu +
#define Ziehedavonab -

Jobst Q. schrieb:
> Aber wem das nicht behagt, für den ist C so flexibel, dass es auch an
> solche absurden Wünsche angepasst werden kann.

Ein kleines Beispiel (Berechnung des größten gemeinsamen Teilers mit dem
Euklidischen Algorithmus):


ggt.c:

1

eine vorzeichenlose Ganzzahl lieferndes Unterprogramm ggT

2

    (vorzeichenlose Ganzzahl a, vorzeichenlose Ganzzahl b)

3

  hier beginnt ein neuer Block

4

    solange a verschieden von 0 ist 

5

      hier beginnt ein neuer Block

6

        vorzeichenlose Ganzzahl t sei ab sofort a  Ende der Anweisung

7

        a sei ab sofort der Rest der Division von b durch a  Ende der Anweisung

8

        b sei ab sofort t  Ende der Anweisung

9

      hier endet ein Block

10

    gib b zurueck  Ende der Anweisung

11

  hier endet ein Block

12

13

eine Ganzzahl lieferndes Hauptprogramm

14

    (ohne Argumente)

15

  hier beginnt ein neuer Block

16

    schreibe die Zeichenkette(Die Ergebnisse sind:)

17

       mit Zeilenvorschub hinaus  Ende der Anweisung

18

    schreibe vorzeichenlos mit Zeilenvorschub

19

      den Ausdruck ggT(36, 24) hinaus  Ende der Anweisung

20

    schreibe vorzeichenlos mit etwas Abstand

21

             vorzeichenlos mit etwas Abstand

22

             vorzeichenlos mit Zeilenvorschub

23

      die Ausdruecke ggT(21, 35), ggT(20, 25) und ggT(21, 25) hinaus

24

      Ende der Anweisung

25

    gib 0 zurueck  Ende der Anweisung

26

  hier endet ein Block

Das ist besser als Basic, Pascal und Cobol zusammen. Die vereinzelt noch
vorkommenden kryptischen Klammern bekommt man sicher auch noch irgendwie
weg :)

Kompilieren, Ausführen und Ausgabe:

1

$ gcc -include dauc.h -o ggt ggt.c

2

$ ggt

3

Die Ergebnisse sind:

4

12

5

7 5 1

Jobst Q. schrieb:
> Ein '{' ist deutlicher und sowohl vom Programmierer
> als auch Compiler schneller zu lesen als ein Wort wie
> HierfängteinneuerBlockan.

> Es war vor Jahrzehnten so gemacht worden und hat sich nun jahrzehntelang
> bewährt.

Und sollte seit rund einem Jahrzehnt der Vergangenheit angehören. Die 
nicht stehengebliebene Weiterentwicklung der IDEs mit den 
Zusatzfunktionen wie Intellisense oder Refactoring machen all dies 
Überflüssig.
Ansätze aus Clean Code zeigen, dass es für die Programmierer viel 
einfacher ist, wenn man konkret beschreibende Strukturen verwendet, als 
kryptische Funktions- und Variablennamen.
Aus diesem Grund verwendet man auch nicht mehr Konstrukte wie Ungarische 
Notation, Variablendeklarationen am Anfang einer Funktion, Vermeidungen 
von Funktionsaufrufen, etc.

Nicht ohne Grund findet Python vermehrt Programmierer aus 
Nicht-Technischen Kreisen.

Yalu X. schrieb:
> $ gcc -include dauc.h -o ggt ggt.c

Diese Zeile fällt aber doch etwas aus dem Rahmen, das versteht doch kein 
Mensch. Ich erinnere mich vage an die Lochkartenära auf der TR440, in 
der auch solche Kommandos lesbarer deutscher Klartext waren, mit 
"übersetze" für den Compiler und "binde" für den Linker, und klar 
verständlicher Parametrisierung.

Und überhaupt - der kryptische Name "ggt". Rückfällig geworden? ;-)

Achim S. schrieb:
> Du verwechselst da was. Variablennamen oder Funktionen sollten nie
> kryptisch sein *). Der Syntaktische Kit aber, beispielsweise { oder ein
> Punkt am Satzende, wie

Syntax und der Rest gehen Hand in Hand.
Man liest ja nicht nur die Variablen- oder Funktionsnamen, sondern eine 
Geschichte.

> for Werkzeug in Werkzeugkiste:

ist nunmal leserlicher als

> for(int i=0; i<Werkzeugkiste.length(); i++)

Wenn man dann noch den C++ Weg geht und Iteratoren verwendet, wird es 
noch unleserlicher. Natürlich hat C++ inzwischen auch Range based loops, 
aber erst seit andere Programmiersprachen dies schon seit langem besser 
gemacht haben.

Yalu X. schrieb:

> ....
> Das ist besser als Basic, Pascal und Cobol zusammen. Die vereinzelt noch
> vorkommenden kryptischen Klammern bekommt man sicher auch noch irgendwie
> weg :)


Richtig. Das ist gut. So gut, daß es jeder schnell verstehen kann und 
daß es auch in 20 Jahren noch von dem ursprünglichen Verfasser geslesen 
und wieder verstanden werden kann. Da macht der einmalige 
Mehraufwand beim Schreiben jeden Zeitnachteil wett.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
(Von dem Beitrag existiert eine Kopie -wird er gelöscht, taucht er bald 
wieder neu auf -weil ein Anderer den gleichen Gedankengang hatte)

MfG Paul

Operator S. schrieb:
> Jobst Q. schrieb:
>> Ein '{' ist deutlicher und sowohl vom Programmierer
>> als auch Compiler schneller zu lesen als ein Wort wie
>> HierfängteinneuerBlockan.
>
>> Es war vor Jahrzehnten so gemacht worden und hat sich nun jahrzehntelang
>> bewährt.
>
> Und sollte seit rund einem Jahrzehnt der Vergangenheit angehören. Die
> nicht stehengebliebene Weiterentwicklung der IDEs mit den
> Zusatzfunktionen wie Intellisense oder Refactoring machen all dies
> Überflüssig.

Wir brauchen auch nicht mehr laufen zu lernen, es gibt ja schon seit 
Jahrhunderten Autos.

> Ansätze aus Clean Code zeigen, dass es für die Programmierer viel
> einfacher ist, wenn man konkret beschreibende Strukturen verwendet, als
> kryptische Funktions- und Variablennamen.

Kannst du uns mal erklären, wie man Namen durch Strukturen ersetzt?

> Aus diesem Grund verwendet man auch nicht mehr Konstrukte wie Ungarische
> Notation, Variablendeklarationen am Anfang einer Funktion, Vermeidungen
> von Funktionsaufrufen, etc.

Was 'man' macht, ist mir eigentlich egal. Ich mache, was sinnvoll ist 
und was sich bei mir bewährt hat. Bei Variablendeklarationen am Anfang 
einer Funktion zB weiß ich, wo ich sie finden kann. Auch wenn ich den 
Text ohne IDE anschaue.

>
> Nicht ohne Grund findet Python vermehrt Programmierer aus
> Nicht-Technischen Kreisen.

Und nicht ohne Grund bleiben Programmierer aus technischen Kreisen bei 
C.

mh schrieb:
> Weil es halt genauso funktioniert:
>
> in Mathe: y=f(x)
> in C:     y=f(x);
>
> Der einzige Unterschied ist der Strichpunkt am Ende.

Nicht ganz. Die C-"funktion" kann überraschenderweise oder meist auch 
beabsichtigterweise irgendwelche Seiteneffekte haben oder ihr 
Rückgabewert hängt kann von mehr als nur den Argumenten abhängen. Die 
mathematische Funktion hingegen hast diesen Nachteil ganz sicher nicht.

Es ist schon ein wenig irreführend in einer imperativen 
Programmiersprache von "Funktion" zu sprechen, besser wäre vielleicht 
"Prozedur".

Axel L. schrieb:
>>> Klasse = Schulklasse,
> Ähnliches Thema, "class" beinhaltet einiges mehr als nur die
> Schulklasse. Vielleicht wäre "Gruppe" die richtigere Übersetzung
> gewesen.

Nein, Klasse passt schon. Auch im Deutschen. Es gibt auch 
Fahrzeugklassen, in der Biologie teilt man Organismen in verschiedene 
Klassen ein, es gibt bestimmte Klassen von Problemen, das Wort Klasse 
passt schon, ist die perfekte Übersetzung, ich wüsste keine bessere.

Bernd K. schrieb:

> Nicht ganz. Die C-"funktion" kann überraschenderweise oder meist auch
> beabsichtigterweise irgendwelche Seiteneffekte haben oder ihr
> Rückgabewert hängt kann von mehr als nur den Argumenten abhängen. Die
> mathematische Funktion hingegen hast diesen Nachteil ganz sicher nicht.
>
> Es ist schon ein wenig irreführend in einer imperativen
> Programmiersprache von "Funktion" zu sprechen, besser wäre vielleicht
> "Prozedur".

Und wenn du das jetzt jemanden erzählst, der das Wort Funktion nicht mit 
Mathematik verbindet, da er nicht mal die Regel Punkt vor Strich kennt, 
wirst du nur blöd angeschaut, aber er weiß auch was eine Funktion ist, 
z.B vom Schraubenzieher ;)

Im allgemeinen muss man sich immer bewusst machen, was ein Wort in 
welchem Zusammenhang bedeutet, abhängig von der Situation. Leider ist 
die Sprache nicht eindeutig und sauber definiert und es herscht oft 
Verwirrung, sogar wenn jeder meint, er hätte es verstanden.

Michael M. schrieb:
> Und wenn du das jetzt jemanden erzählst, der das Wort Funktion nicht mit
> Mathematik verbindet, da er nicht mal die Regel Punkt vor Strich kennt,
> wirst du nur blöd angeschaut, aber er weiß auch was eine Funktion ist,
> z.B vom Schraubenzieher ;)

Wenn derjenige die Punkt-vor-Strich-Regel nicht kennt, wird er noch ganz
andere Probleme mit der Programmiererei haben, da er u.U. nicht einmal
einen arithmetischen Term korrekt hinschreiben kann ;-)

Bernd K. schrieb:
> Nicht ganz. Die C-"funktion" kann überraschenderweise oder meist auch
> beabsichtigterweise irgendwelche Seiteneffekte haben oder ihr
> Rückgabewert hängt kann von mehr als nur den Argumenten abhängen. Die
> mathematische Funktion hingegen hast diesen Nachteil ganz sicher nicht.

Die Nebeneffekte sind ja nicht immer nur nachteilhaft, da ohne sie bspw.
die printf-Funktion der C-Bibliothek nicht realisierbar wäre. In rein
funktionalen Sprachen wie bspw. Haskell, wo es nur "echt mathematische"
Funktionen gibt, mussten die Entwickler bei den I/O-Funktionen ganz neue
Wege gehen, um nicht gegen das "Reinheitsgebot" zu verstoßen.

> Es ist schon ein wenig irreführend in einer imperativen
> Programmiersprache von "Funktion" zu sprechen, besser wäre vielleicht
> "Prozedur".

Als Pascal-Versauter denke ich bei "Prozedur" eher an ein Unterprogramm
ohne Rückgabewert. Unterprogramme mit Rückgabewert heißen auch in
Pascal "Funktion", unabhängig davon, ob sie Nebeneffekte haben oder
nicht. Da in C alle Unterprogramme einen Rückgabewert (und sei es nur
ein Pseudowert vom Typ void) haben, entsprechen sie dem, was in Pascal,
Ada, Fortran, Basic und vielen anderen Sprachen "Funktion" genannt wird.
So ist der Begriff wenigstens innerhalb der imperativen Sprachen
weitgehend einheitlich.

Achim S. schrieb:
> sobald Sprache eindeutig
> ist, ist sie tot. Und vice versa. Für Programmiersprachen ok, bei
> natürliche Sprachen gibt's dann keine Weiterentwicklung.

Gerade da gibt es einen deutlichen Unterschied zwischen natürlichen 
Sprachen und Programmiersprachen.

Natürliche Sprachen sind für die analoge Welt, in der es keine 
Eindeutigkeit gibt. Sie in eindeutige Begriffe zu fassen ist eine 
Digitalisierung, bei der alle Zwischentöne wegfallen. Da ist es Aufgabe 
der Poesie, durch Uneindeutigkeit den Verlust des Analogen zu 
verhindern.

Programmiersprachen sind aber Teil einer digitalen Welt, zur 
Kommunikation mit Maschinen bzw Compilern. Da ist Eindeutigkeit möglich 
und erwünscht, da Uneindeutigkeiten auch immer mögliche Fehlerquellen 
sind. Bei Programmiersprachen ist Eindeutigkeit keine Todesursache, 
sondern ein Grund, warum sie überleben. Auch dann, wenn sie bei vielen 
unbeliebt sind.

Jobst Q. schrieb:
> Programmiersprachen sind aber Teil einer digitalen Welt, zur
> Kommunikation mit Maschinen bzw Compilern. Da ist Eindeutigkeit möglich
> und erwünscht, da Uneindeutigkeiten auch immer mögliche Fehlerquellen
> sind

Eben das fasziniert  mich immer wieder:
So ein Prozessor macht immer wieder das Gleiche, Millionen/Milliarden 
mal die Sekunde. Und nie schleicht sich ein Fehler ein.

Achim S. schrieb:
> Tod einer Sprache heißt nicht "verschwinden". Sondern, dass sie sich
> nicht weiterentwickelt.

Eine merkwürdige Auffassung von Tod.

> Und ja, alle paar Jahre gibt es z.B. einen neuen
> C-Standard, aber die wirklichen Weiterentwicklungen finden eher in
> (jeweils) neuen Sprachen statt.

Diese neuen Sprachen bauen auf bewährten Konzepten auf. Beispielsweise 
sind C++, C#, Java, Kotlin usw Abkömmlinge von C. Damit ist das pure C 
aber noch nicht tot.

Gerade die Eindeutigkeit von purem C ist auf vielen Gebieten wie 
Systemprogrammierung (zB Linux) von Vorteil. So vermindert das 
Versteckspiel von C++ die Durchschaubarkeit, die klare Zuordnung von 
Quellcode zu Binärcode, die bei purem C noch möglich ist.

Achim S. schrieb:
> Weil es in diesem Thread gerade nicht oT ist: sobald Sprache eindeutig
> ist, ist sie tot. Und vice versa.

Ich denke nicht, dass es jemals eine natürliche Sprache gab, die 
eindeutig gewesen wäre. Auch nicht tot. Sprachen sind nicht durch ihre 
aktive Verwendung und Entwicklung uneindeutig, sondern z.B. aufgrund 
Mehrdeutigkeit von Begriffen und grammatikalischen Bezügen. Zudem 
verschwinden mit den Kennern der Sprache genau jene Personen, die bei 
der Interpretation helfen können, so dass mit dem Tod die Mehrdeutigkeit 
nicht ab- sondern zunimmt.

Bei Programmiersprachen sieht das auch nicht viel besser aus. C erlaubt 
Programme, deren exakte Funktion zwar reproduzierbar, aber nicht vom 
Sprachstandard festgelegt ist (implementation-defined behaviour). Damit 
ist es bei Verwendung solcher Kontruktionen mehrdeutig, weil ein >> 
Operation auf Typen mit Vorzeichen mehrere Bedeutungen haben kann. Wenn 
man morgen aufhört, C weiter zu entwickeln oder neuen Programme darin zu 
schreiben, würde sich an dieser Mehrdeutigkeit nichts ändern.

Über die Lebensdauer gesehen ist C inhärent mehrdeutig, beispielsweise 
weil im K&R Standard nicht eindeutig festgelegt war, wie die integer 
promotion mit dem Vorzeichen umgeht (sign preserving vs value 
preserving). Das kam erst mit ANSI C.

Zur Feststellung der Eindeutigkeit muss man sich also auf einen 
bestimmten Standard festlegen. Das wiederum funktioniert unabhängig 
davon, ob es künftig noch neue Standards geben wird oder nicht.

A. K. schrieb:
> Zudem
> verschwinden mit den Kennern der Sprache genau jene Personen, die bei
> der Interpretation helfen können, so dass mit dem Tod die Mehrdeutigkeit
> nicht ab- sondern zunimmt.

Ist es nicht so, dass im Lauf der Zeit alte Begriffe auf neue Dinge 
angewandt werden und so eine neue Bedeutung erhalten?

Begriffe einer toten Sprache können keine neuen Bedeutungen mehr 
erhalten, also müsste doch die Mehrdeutigkeit eines Begriffes konstant 
bleiben - oder übersehe ich was?

> Damit
> ist es bei Verwendung solcher Kontruktionen mehrdeutig, weil ein >>
> Operation auf Typen mit Vorzeichen mehrere Bedeutungen haben kann.

Welche Bedeutung ein Symbol der Programmiersprache hat, hängt vom 
Kontext ab - genau wie bei natürlichen Sprachen auch. Nur dass der 
Kontext eines natürlichen Begriffes deutlich umfangreicher sein kann, 
als der eines Stückes Programmcode.

> Über die Lebensdauer gesehen ist C inhärent mehrdeutig, beispielsweise
> weil im K&R Standard nicht eindeutig festgelegt war, wie die integer
> promotion mit dem Vorzeichen umgeht (sign preserving vs value
> preserving). Das kam erst mit ANSI C.

Im Gegensatz zu natürlicher Sprache war bei C immer definiert, was 
implementierungsabhängig ist und was nicht. Wo solche Uneindeutigkeiten 
auftreten, hängt vom Implementierungskontext ab. Innerhalb eines 
Implementierungskontextes war es aber immer schon eindeutig.

Es gab mal eine Programmiersprache mit mehrdeutiger Grammatik: Algol 68. 
Der Fehler in der Sprachdefinition wurde erst bemerkt, als versucht 
wurde, mittels Compiler-Compiler einen Zerteiler dafür zu konstruieren: 
der fand, dass manche Ausdrücke der Sprache zu mehreren verschiedenen 
Strukturbäumen reduziert werden konnten.

Damit war die Sprache tot.

Uhu U. schrieb:
> Ist es nicht so, dass im Lauf der Zeit alte Begriffe auf neue Dinge
> angewandt werden und so eine neue Bedeutung erhalten?

Auch dies. Aber ein Begriff kann auch gleichzeitig mehrere Bedeutungen 
haben, die sich allenfalls aus dem Kontext heraus erschliessen. Das 
wiederum ist nicht immer eindeutig.

> also müsste doch die Mehrdeutigkeit eines Begriffes konstant
> bleiben - oder übersehe ich was?

Eine obere Grenze N für die Mehrdeutigkeit angeben zu können macht eine 
Sprache nur dann eindeutig, wenn N=1. Es ist also nur klar, dass sie aus 
dieser Logik heraus mit dem Tod nicht noch mehrdeutiger werden kann als 
sie schon ist.

Aber wie ich oben schon schrieb, nimmt die Mehrdeutigkeit zu, wenn durch 
das Hinscheiden der Sprecher die Kenntnis der möglichen Bedeutungen 
abnimmt.

Uhu U. schrieb:
> Im Gegensatz zu natürlicher Sprache war bei C immer definiert, was
> implementierungsabhängig ist und was nicht.

Vor ANSI C gab es für die integer promotion keine vollständige 
Festlegung, was dem Umgang mit dem Vorzeichen bei Typen kleiner als 
"int" angeht. Das war auch nicht als implementation-defined festgelegt, 
sondern fehlte schlicht und einfach.

Daraus entwickelten sich 2 Schulen: Die eine machte bei einem Operanden 
ohne Vorzeichen die ganze Rechnung vorzeichenlos. Die andere präferierte 
vorzeichenbehaftete Typen, wenn die möglichen Werte darin dargestellt 
werden können. ANSI entschied sich für Letzteres.

A. K. schrieb:
> Aber wie ich oben schon schrieb, nimmt die Mehrdeutigkeit zu, wenn durch
> das Hinscheiden der Sprecher die Kenntnis der möglichen Bedeutungen
> abnimmt.

Das ist aber kein Manko der Sprache, sondern eines der Sprecher der 
toten Sprache.

Uhu U. schrieb:
> Es gab mal eine Programmiersprache mit mehrdeutiger Grammatik:

War diese Mehrdeutigkeit so krass und so tief, dass sie nicht per 
Definition von einem Algol 69 behebbar war?

Auch die Syntax von C ist nicht sehr glücklich definiert, da der Bezug 
des "else" auf das zugehörige "if" nur durch die exakte Formulierung der 
Grammatik festgelegt wird, nicht schon durch das Sprachbild per se. Das 
ist zwar harmlos, aber diverse neuere Sprachen machen es vor vorneherein 
besser.

Kann es sein dass die deutsche Sprache in einigen Wörtern bis zu 3 
Begriffe reinpackt ?

Wie steht es da mit der englischen Sprache ?

A. K. schrieb:
> Auch die Syntax von C ist nicht sehr glücklich definiert, da der Bezug
> des "else" auf das zugehörige "if" nur durch die exakte Formulierung der
> Grammatik festgelegt wird, nicht schon durch das Sprachbild per se. Das
> ist zwar harmlos, aber diverse neuere Sprachen machen es vor vorneherein
> besser.

Das ist doch eindeutig geregelt: Das "else" bezieht sich immer auf das 
vorherige "if" im selben Block. Anfang und Ende eines Blocks sind mit 
'{' und '}' auch ganz klar. Klarer als zB in Phyton, wo Blöcke durch 
Einrückungen, also durch die Anzahl von Leerzeichen am Zeilenanfang 
bestimmt werden.

Wer Probleme mit exakten Formulierungen hat, sollte sich lieber einen 
anderen Beruf suchen. Denn Gedanken lesen kann kein Compiler, auch nicht 
in neueren Sprachen.

H-G S. schrieb:
> Kann es sein dass die deutsche Sprache in einigen Wörtern bis zu 3
> Begriffe reinpackt ?
>
> Wie steht es da mit der englischen Sprache ?

Im Englischen ist es noch viel schlimmer. Lass dir mal die vielen 
Bedeutungen von 'jack', 'power' oder 'trip' anzeigen.

A. K. schrieb:
> War diese Mehrdeutigkeit so krass und so tief, dass sie nicht per
> Definition von einem Algol 69 behebbar war?

Es gab diese Revision 1975. Allerdings ist die Sprache ein wahres 
Ungetüm, ein akademisches Studienobjekt, aber für den praktischen 
Einsatz viel zu unübersichtlich und zu kompliziert.

-> https://en.wikipedia.org/wiki/ALGOL_68#Revisions

Das war eine lustige Geschichte irgendwann im 2. Drittel der 1970er: 
Gerhard Goos, der Compilerbau-Guru an der Uni Karlsruhe (er hatte in den 
Anfängervorlesungen Anfang der 70er Algol 68 als das Non plus Ultra der 
Programmiersprach-Entwicklung angepriesen und wir mussten erste 
Programmierübungen damit machen, obwohl es keinen Compiler dafür gab) 
hatte sich mit dem Bau eines Compilers versucht und das Projekt 
eingestellt, als die Probleme mit der Sprachdefinition zu Tage kamen.

Sehr zu seinem Ärger gab es dann 76 oder so einen Vortrag von einem 
französischen Mineralogen im Informatik-Kolloquium, der meinte, Algol 68 
sei für seine Problem wie geschaffen und sich einfach selbst einen 
Compiler strickte. Auf die Mehrdeutigkeitsproble angesprochen, fuhr der 
Bursche nur seinen Charme aus und grinste wie ein Honigkuchenpferd.

Der Compiler war im Rechenzentrum verfügbar und wir sahen ihn uns etwas 
genauer an. Besonders interessant war die Datei mit den 
Fehlermeldungs-Texten. Es gab dort eine Meldung:

1

 Fatal: program too sopisticated - compiler confused

Goos flüchtete sich in beißenden Spott...