Hallo mal eine Allgemeine Frage zur Programmierung: Je nach Programmiersprache versucht man ja mehr oder weniger nah an die "normale" im, englischsprachigen, Alltag gesprochen Sprache an zu knüpfen. Aber letztendlich gelingt dies irgendwie doch nie (insbesondere im µC Bereich) wenn es auch nur ganz leicht ins Detail geht. Mal ist z.B. von einen Unterprogramm die Rede (Basic ?) mal ist es eine Funktion (C) ein anderes mal sind es Methoden... Und alles irgendwie Ähnlich im Detail dann doch irgendwie verschieden. Wenn man es einmal verstanden hat "Der Knoten im Hirn geplatzt ist" ist es meist recht einfach und logisch- aber bis es soweit ist war es zumindest für mich ein steiniger und verwirrender Weg. Warum wird z.B. der so mannigfaltig belegte Begriff "Funktion" bei der Sprache C verwendet? Den gibt es in der Mathematik, eben bei der Programmierung, auch in der Alltagssprache und sicherlich noch in Bereichen welche mir jetzt nicht in den Sinn kommen. Hinzu kommt dann auch noch oft das selbst in der Lehrliteratur fast immer von einer Funktion im Alltagssinn gesprochen wird (Irgendeine erwünschter Vorgang und Reaktionen auf irgendwas soll letztendlich durch Hardware und das Programm ausgeführt werden) und dann der Begriff Funktion aber auch im speziellen C- Zusammenhang erscheint - alles sehr (unnötig?) verwirrend für den Anfänger der noch den "Knoten im Hirn" hat bzw. noch nie vorher Programmiert hat. Warum solch verwirrende und ebenfalls vielfach im Alltag anders belegte Begriffe wie "Methoden, Klassen, Bibliotheken...? Irgendwie sind diese zwar passend aber auch erst mal extrem verwirrend, eben weil man ganz andere Bilder im Kopf hat (z.B. Klasse = Schulklasse, Biliothek = Bücher und Filme ausleihen...) die teilweise sogar Emotional belegt sind. Es klingt jetzt erst mal seltsam aber: Beim Einstieg in die Programmierung (zugegeben µC nicht auf dem Computer) habe ich mich erst mal informiert wie ein µC (AVR) Hardwaremäßig arbeitet - und auch das Datenblatt genauer angesehen inklusive Timer, Zähler usw. Mit dieser Info habe ich mir direkt (theoretisch) an Assembler angesehen - und obwohl Assembler recht aufwendig und umständlich ist, kam mir diese Programmiersprache wesentlich logischer und verständlicher vor als die komfortablen und (wenn verstanden - aber erst dann !)einfacheren Hochsprachen. Verdammt nochmal: Warum diese, zwar richtigen, aber für den Einsteiger sehr verwirrende Begrifflichkeiten dann noch garniert mit 1001 Sonderzeichen die "Nichtprogrammierer" nie verwendet, warum teilweise absolut Lebensfremde Bezeichnungen und Begrifflichkeiten wie Zustandsmaschine, inkrementieren, prozedural und und und... 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...? Ich habe mit teilweise Literatur angesehen die sich direkt an Kinder wendet - sehr einfach und oft "niedlich" - aber Begrifflichkeiten wie Funktion, Bibliothek, Methode waren mir auch dort nicht sofort wirklich klar. Muss man sein Gehirn (als Erwachsener) erstmal umprogrammieren und Programmieren zu verstehen? Denn wenn man es (endlich) mal verstanden hat, haben die ganzen Begrifflichkeiten und die Ideen dahinter einen Sinn und sind auch recht einfach, aber... siehe oben ?! Cleve
:
Verschoben durch User
Man kann sich auch anstellen. Cleve schrieb: > Muss man sein Gehirn (als Erwachsener) erstmal umprogrammieren und > Programmieren zu verstehen? Ja.
Das liegt daran, weil ... Ach nee, ich mach lieber Schluß für heute. Schönen Feierabend !
Cleve schrieb: > Warum wird z.B. der so mannigfaltig belegte Begriff "Funktion" bei der > Sprache C verwendet? > > Den gibt es in der Mathematik, eben bei der Programmierung,... Weil es halt genauso funktioniert: in Mathe: y=f(x) in C: y=f(x); Der einzige Unterschied ist der Strichpunkt am Ende.
Beitrag #5118016 wurde von einem Moderator gelöscht.
Cleve schrieb: > Mal ist z.B. von einen Unterprogramm die Rede (Basic ?) mal ist es eine > Funktion (C) ein anderes mal sind es Methoden... > Und alles irgendwie Ähnlich im Detail dann doch irgendwie verschieden. Ja, es gibt überflüssiges theoretisches Beiwerk in der Programmiererei (so wie überall Anders auch). Aber wenn Du bereits diese elementaren und für die Praxis hochrelevanten Konzepte darin einreihst (offensichtlich noch nicht mal ein Gespür dafür hast, was der Unterschied zwischen "ähnlich" und "verschieden" ist), gehörst Du zu denen, die sich aus der Programmierung lieber heraushalten sollten. Bedenke die erste goldene Regel für Programmierer: Schreibe deinen Code so, als wäre derjeinige, der ihn übernehmen und weiterführen muss, ein Serienkiller ist, der deine Adresse kennt. Mit dem aus deinem Geseiere herausscheinenden Verständnis von Codierung darfst Du Dich dann jetzt schon vom Bestatter deiner Wahl vermessen lassen. Sachen gibt's...
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.
:
Bearbeitet durch Moderator
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. Welche Begriffe sollten denn sonst verwendet werden? Cleve schrieb: > Klasse = Schulklasse, > Biliothek = Bücher und Filme ausleihen... Klasse ist allgemein eine Sammlung von Gemeinsamkeiten, wie man am Wort Klassifizierung sieht. In einer Bibliothek ist Wissen gesammelt, aus dem man sich das, was man braucht, herausnehmen kann. Cleve schrieb: > Zustandsmaschine, inkrementieren, prozedural Was denn stattdessen? Inkrementieren=Erhöhen? Inkrementieren ist Erhöhen um eins.
Cleve schrieb: > eben weil man ganz andere Bilder im Kopf hat Schon der Titel belegt eine völlig falsche Auffassung: mehrdeutig ist die Alltagssprache, bzw. das Leben ganz allgemein. 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. Ein Computer mit einem bestimmten Programm macht auch immer dasselbe, deine Heizungsregelung macht dir nicht die Wohnung kalt weil sie gerade schlechter Laune ist. In Fachbereichen sind i.A. auch Bezeichnungen exakt definiert, z.B. die Funktion in der Mathematik ebenso wie in C. Wenn es in Basic Unterprogramm heisst liegt das schlicht daran, dass es eben eine andere Sprache ist. Man kann sich doch auch nicht darüber beschweren, dass der deutsche Fluss im Englischen River heisst. Wenn man damit überfordert ist, sollte man sich weder mit natürlichen noch mit Computersprachen befassen. Ist wohl schon zuviel als Antwort auf einen Trollbeitrag. Georg
Cleve schrieb: > Muss man sein Gehirn (als Erwachsener) erstmal umprogrammieren und > Programmieren zu verstehen? Der Mensch entstammt dem Tierreich, sein Gehirn ist den Bedürfnissen des Tierreiches angepasst insbesonders dem nach Arterhaltung und Fortpflanzung. Programmierung hat mit Tierreich nichts gemein, deshalb muss das Tier Mensch zum Programmieren sein Hirn grümdlichst umstruktieren Und deshalb tut sich der Programierer mit seinem ent-Tier-ten Gehirn so schwer mit der Fortpflanzung.
Cleve schrieb: > dann noch garniert mit 1001 > Sonderzeichen DAS ist ja nun wirklich nicht mehr nötig heute. 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. Aber eben; nur tote Fische schwimmen mit dem Strom... Gruss Chregu PS: Danke schonmal für die Negativbewertungen!
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-
Cleve schrieb: > Mal ist z.B. von einen Unterprogramm die Rede (Basic ?) mal ist es eine > Funktion (C) ein anderes mal sind es Methoden... Zum einen entwickelt sich die Sprache für neue Bereiche weiter > Und alles irgendwie Ähnlich im Detail dann doch irgendwie verschieden. Zum anderen galt es hier ja gerade, unterschiedliche Konzepte unterschiedlich zu benennen. In C wurden aus den Pascalschen Funktionen und Prozeduren halt nur Funktionen. Und Unterprogramme (ohne "Funktionswerte") waren wieder ein wenig anders. > Verdammt nochmal: Warum diese, zwar richtigen, aber für den Einsteiger > sehr verwirrende Begrifflichkeiten dann noch garniert mit 1001 > Sonderzeichen die "Nichtprogrammierer" nie verwendet, Das oben war die "Beschreibung der Programmiersprache". Die erfolgt in möglichst intuitiv verständlicher Prosa (langform). Die Programmierung selber muss aber effizient zu schreiben und vor allem zu lesen sein. Das ist wie in der Mathematik: --> y=5+7 erscheint Dir heute selbstverständlich. --> "Sei eine abstrakte Menge mit Namen y die Summe aus der Zahl 5 mit der Zahl 7" ist schwieriger zu lesen und zu schreiben. > Muss man sein Gehirn (als Erwachsener) erstmal umprogrammieren und > Programmieren zu verstehen? Du hast einfach nur zu wenig Zeit und zuviel Frust. Wenn Du Chinesisch lernen müstest, so würdest Du genauso schimpfen, im Gegensatz zum Kind.
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.
Christian M. schrieb: > Cleve schrieb: >> dann noch garniert mit 1001 Sonderzeichen > > DAS ist ja nun wirklich nicht mehr nötig heute. 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. Das lese ich ja jetzt erst. Meinst Du das Ernst oder schreibst Du beruflich keine Software? Findest Du das bei Mathematischen Ausdrücken auch dumm? Wenn 'Begin' zu '{' wird, dann ist das ein Sprung, wie von römischen Zahlen zum Stellenwert-System.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...
Georg A. schrieb: > 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. zustimm. ich hatte grade gestern wieder einen anruf das ein anwender "nicht drucken kann". man kann nicht voraussetzen das leute auch nur ihr problem in einer art beschreiben können, die in irgendeiner weise zur problemlösung beitragen kann - da fehlt das analytische denken. Cleve schrieb: > Warum solch verwirrende und ebenfalls vielfach im Alltag anders belegte > Begriffe wie > "Methoden, Klassen, Bibliotheken...? > Irgendwie sind diese zwar passend aber auch erst mal extrem verwirrend, > eben weil man ganz andere Bilder im Kopf hat (z.B. Klasse = Schulklasse, > Biliothek = Bücher und Filme ausleihen...) die teilweise sogar Emotional > belegt sind. wie siehts denn mit "vergaser", "kupplung" und "kotflügel" aus, oder "speicher", "maus" und "lautsprecher"? natürlich benutzen fachgebiete fachbegriffe, meißt entlehnt aus dem alltäglichen sprachschatz und belegt mit neuen bedeutungen die der ursprünglichen bedeutung irgendwie nahe kommen. zu kompliziert sich da rein zu denken? -> "ich kann nicht drucken".
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? ;-)
:
Bearbeitet durch User
Operator S. schrieb: > 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. Du verwechselst da was. Variablennamen oder Funktionen sollten nie kryptisch sein *). Der Syntaktische Kit aber, beispielsweise { oder ein Punkt am Satzende, wie Jobst Q. schon schrieb: > hieristderSatzzuende *) Wie Konfuzius schon sagte (Wenn die Begriffe sich verwirren, ist die Welt in Unordnung), ist die Benamung mit das wichtigste in guten Programmen. Bzw. die Namenbildungsregeln. Es muss intuitiv klar sein, wie eine neue Variable (Funktion, Struktur, ) wohl bezeichnet würde. Und den Kollegen muss Intuitiv klar sein, welcher Art sie/es/er ist. Und nein, wie Du bin ich der Meinung: Ungarische Notation ist nicht intuitiv sondern kryptischer Mist.
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.
Michael M. schrieb: > Leider ist die Sprache nicht eindeutig und sauber definiert und es > herscht oft Verwirrung, sogar wenn jeder meint, er hätte es verstanden. Weil es in diesem Thread gerade nicht oT ist: sobald Sprache eindeutig ist, ist sie tot. Und vice versa. Für Programmiersprachen ok, bei natürliche Sprachen gibt's dann keine Weiterentwicklung.
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.
Jobst Q. schrieb: > Bei Programmiersprachen ist Eindeutigkeit keine Todesursache, > sondern ein Grund, warum sie überleben. Auch dann, wenn sie bei vielen > unbeliebt sind. Tod einer Sprache heißt nicht "verschwinden". Sondern, dass sie sich nicht weiterentwickelt. Und ja, alle paar Jahre gibt es z.B. einen neuen C-Standard, aber die wirklichen Weiterentwicklungen finden eher in (jeweils) neuen Sprachen statt.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.