Prozedur und Funktion

[mngbd]

volkard schrieb:

Neulich fragte mich ein Schüler, weshalb die Alten zwischen Prozedur und Funktion überhaupt unterschieden hatten. Ich konnte ihm keine Antwort geben. Technischerseits ist die Unterscheidung ja Quatsch. Und gerade die Alten waren ja recht technisch. Ein Mysterium?

Das hab ich mich auch schon gefragt. Liegt's vielleicht daran, dass die Alten die Prozedur als syntactic sugar für goto-goto oder gosub-return eingeführt haben? Oder an was ganz anderem?

[abc.w]

Prozeduren haben keinen Rückgabewert

[Michael E.]

Du hast die Frage verstanden.

[Zeus]

abc.w schrieb:

Prozeduren haben keinen Rückgabewert

Genau, und der Unterschied wird in der Syntax getroffen. Siehe Pascal,...

[SeppJ]

Zeus schrieb:

abc.w schrieb:

Prozeduren haben keinen Rückgabewert

Genau, und der Unterschied wird in der Syntax getroffen. Siehe Pascal,...

Es gibt ja auch einen syntaktischen Unterschied: Funktionen können als R-value dienen, Prozeduren nicht. Ist dies vielleicht, was die Altvorderen meinten?

[Gast]

mngbd schrieb:

volkard schrieb:

Neulich fragte mich ein Schüler, weshalb die Alten zwischen Prozedur und Funktion überhaupt unterschieden hatten. Ich konnte ihm keine Antwort geben. Technischerseits ist die Unterscheidung ja Quatsch. Und gerade die Alten waren ja recht technisch. Ein Mysterium?

Das hab ich mich auch schon gefragt. Liegt's vielleicht daran, dass die Alten die Prozedur als syntactic sugar für goto-goto oder gosub-return eingeführt haben? Oder an was ganz anderem?

Vielleicht wollten sie eine Unterscheidung zwischen Funktion (= mathematisches Objekt) und Prozedur (= Unterprogramm für einen Computer) erreichen.

Für jemanden, der den Funktionsbegriff aus dem Mathematikunterricht kennt, kann das, was in C++ als Funktion bezeichnet wird, auf den ersten Blick irreführend sein.

[volkard]

Z schrieb:

Vielleicht wollten sie eine Unterscheidung zwischen Funktion (= mathematisches Objekt) und Prozedur (= Unterprogramm für einen Computer) erreichen.

Für jemanden, der den Funktionsbegriff aus dem Mathematikunterricht kennt, kann das, was in C++ als Funktion bezeichnet wird, auf den ersten Blick irreführend sein.

Daß man damals auf Anfänger geachtet hat, halte ich für unwahrscheinlich.
Aber erstmal suchen, ab wann die Unterscheidung zu sehen ist.
Algol68 http://www.algol68.org/ hat nur PROC for Funktionen und Prozeduren und kann anscheinend VOID zurückgeben (Seite 168), um Prozeduren zu machen.
Fortran scheint seit F77 zu unterscheiden. https://srv.rz.uni-bayreuth.de/lehre/fortran90/vorlesung/V07/V07.html#e

Also ist es vielleicht gar so, daß die Alten es wie in C machten, danach eine Zeit der Strukturierten Bemutterung aufkam, wo man unterscheiden wollte, und die alte Weise durch C bis heute gerettet wurde.

Dazu würde auch passen, daß in http://de.wikipedia.org/wiki/Pascal_(Programmiersprache) "strikte Trennung zwischen Funktionen und Prozeduren" aufgeführt ist. Ist Wirth dran schuld?

(Basic hatte damals gar keine Prozeduren oder Funktionen, war also eher wie Assembler.)

[audacia]

Im Wirthschen Pascal waren, soweit ich weiß, Prozeduren (Statements) und Funktionen (Ausdrücke) insofern klar getrennt, als daß man etwa eine Funktion nicht aufrufen konnte, ohne ihren Rückgabewert zu speichern. Eine Funktion konnte nicht wie eine Prozedur behandelt werden. Welchen Sinn man dahinter sah, ist mir nicht klar (vielleicht wollte man verhindern, daß der Programmierer den Rückgabewert "vergißt"; jedenfalls war der Idee, genau wie Checked Exceptions oder anderen kurzsichtigen Versuchen, Sauberkeit zu erzwingen, glücklicherweise keine lange Dauer beschieden).

[Gast]

volkard schrieb:

Z schrieb:

Vielleicht wollten sie eine Unterscheidung zwischen Funktion (= mathematisches Objekt) und Prozedur (= Unterprogramm für einen Computer) erreichen.

Für jemanden, der den Funktionsbegriff aus dem Mathematikunterricht kennt, kann das, was in C++ als Funktion bezeichnet wird, auf den ersten Blick irreführend sein.

Daß man damals auf Anfänger geachtet hat, halte ich für unwahrscheinlich.

Ich dachte nicht an Anfänger, aber vielleicht kam jemand auch so auf die Idee, dass eine Unterscheidung nötig wäre.

Eine Funktion ist etwas sehr abstraktes, wie eine Einbahnstrasse zwischen zwei Welten. Dagegen ist eine Prozedur schon konkreter, z.B. eine Handlungsanweisung für den Computer. Man kann mit Prozeduren Funktionen simulieren, aber eigentlich bleiben es trotzdem Prozeduren. Ausser in funktionalen Programmiersprachen, wo auf einer höheren Abstraktionsebene programmiert wird. Aber von solchen Sprachen habe ich keine Ahnung bzw. ich kann mir nicht vorstellen, wie man mit einer funktionalen Sprache "normale" Programme schreiben kann. Ausser man hält sich ein Hintertürchen offen, so dass man doch sowas wie Prozeduren hat.

Audacia: Pascal ist, oder war, eine Lehrsprache. In solchen Sprachen mag es manchmal richtig sein, dem Programmierer Restriktionen aufzuerlegen. In real angewendeten Sprachen sind sämtliche Hindernisse IMHO eher kontraproduktiv.

[audacia]

Z schrieb:

Audacia: Pascal ist, oder war, eine Lehrsprache. In solchen Sprachen mag es manchmal richtig sein, dem Programmierer Restriktionen aufzuerlegen. In real angewendeten Sprachen sind sämtliche Hindernisse IMHO eher kontraproduktiv.

Ganz richtig. Deshalb verschwand diese Regulation in allen realwelttauglichen Pascal-Implementationen seit Turbo Pascal auch ganz fix von der Bildfläche

[Gast]

mngbd schrieb:

Liegt's vielleicht daran, dass die Alten die Prozedur als syntactic sugar für goto-goto oder gosub-return eingeführt haben? Oder an was ganz anderem?

Ich behaupte mal, daß die Unterscheidung zwischen Prozedur und Funktion tatsächlich einen technischen Hintergrund hatte:

Anfangs konnten Variablen nur "global" (und nur global erreichbar) sein. Erst als eine/die CPU ausreichend viele Register hatte, konnten Variablen auch "nicht global" (und somit nicht global erreichbar) sein.

Allerdings gab es zur Zeit dieser "neuartigen" Erfindung bereits Programmiersprachen (und Denkweisen ).

[volkard]

Die Zahl der Register hat nix damit zu tun, ob lokale Variablen möglich sind. Und inwiefern sollte das für oder gegen eine Unterscheidung von Prozedur und Funktion sprechen?

[DEvent]

audacia schrieb:

Im Wirthschen Pascal waren, soweit ich weiß, Prozeduren (Statements) und Funktionen (Ausdrücke) insofern klar getrennt, als daß man etwa eine Funktion nicht aufrufen konnte, ohne ihren Rückgabewert zu speichern. Eine Funktion konnte nicht wie eine Prozedur behandelt werden. Welchen Sinn man dahinter sah, ist mir nicht klar (vielleicht wollte man verhindern, daß der Programmierer den Rückgabewert "vergißt"; jedenfalls war der Idee, genau wie Checked Exceptions oder anderen kurzsichtigen Versuchen, Sauberkeit zu erzwingen, glücklicherweise keine lange Dauer beschieden).

Checked Exceptions sind in Java schon auf Dauer (ich finde die Idee der checked exceptions gut). Oder was meinst du?

Z schrieb:

Für jemanden, der den Funktionsbegriff aus dem Mathematikunterricht kennt, kann das, was in C++ als Funktion bezeichnet wird, auf den ersten Blick irreführend sein.

Wie das?

int x = 5;
int y = y(5);
// und
y = f(x)

[volkard]

Du findest auch global failing gut. hihihi.
Das spricht eher gegen checked exceptions, als dafür.

[audacia]

DEvent schrieb:

Checked Exceptions sind in Java schon auf Dauer

Ja, loswerden kann man die wohl nicht mehr, nur noch totschweigen und möglichst nicht benutzen. (Genau wie export template in C++.)

DEvent schrieb:

ich finde die Idee der checked exceptions gut

Ich finde die Idee des Kommunismus auch gut.

DEvent schrieb:

Z schrieb:

Für jemanden, der den Funktionsbegriff aus dem Mathematikunterricht kennt, kann das, was in C++ als Funktion bezeichnet wird, auf den ersten Blick irreführend sein.

Wie das?

In den meisten Programmiersprachen mit prozeduralen Wurzeln können Funktionen Nebeneffekte haben. Der Funktionsbegriff der Mathematik hat aber überhaupt nichts mit Anweisungen, Auswirkungen, Effekten zu tun; eine Funktion tut nichts, sie ist nur eine Abbildung aus einer Menge in eine andere.

[DEvent]

audacia schrieb:

DEvent schrieb:

Checked Exceptions sind in Java schon auf Dauer

Ja, loswerden kann man die wohl nicht mehr, nur noch totschweigen und möglichst nicht benutzen. (Genau wie export template in C++.)

DEvent schrieb:

ich finde die Idee der checked exceptions gut

Ich finde die Idee des Kommunismus auch gut.

Ich finde es besser zu wissen, welche Exceptions eine Methode werfen kann und welche ich fangen sollte. Besser als in C++/C# wo eine Methode alles werfen kann. Da die Dokumentation nicht immer aktuell ist, ist es besser dass es der Compiler für mich Überprüfen kann.

Wieso sollte man die totschweigen und nicht benutzen? Besser als dann das Programm sich beendet, weil man eine Exception vergessen hat zu fangen, oder ein Programm läuft weiter, weil man eine Exception zu viel gefangen hat.

Wie kann man eigentlich const-correctnes von C++ gut finden, aber Checked Excpetions schlecht?

[volkard]

DEvent schrieb:

Wie kann man eigentlich const-correctnes von C++ gut finden, aber Checked Excpetions schlecht?

Zum Beispiel "Ein anderer Einwand ist, dass aufgrund der Deklaration der Exceptions in den Methodensignaturen allgemein verwendbare Hilfsklassen oder Interfaces, insbesondere als Teil von Entwurfsmustern, oft nicht sinnvoll operabel sind mit Klassen, die Checked Exceptions verwenden." http://de.wikipedia.org/wiki/Ausnahmebehandlung#Checked_Exceptions

[audacia]

DEvent schrieb:

Ich finde es besser zu wissen, welche Exceptions eine Methode werfen kann und welche ich fangen sollte. Besser als in C++/C# wo eine Methode alles werfen kann. Da die Dokumentation nicht immer aktuell ist, ist es besser dass es der Compiler für mich Überprüfen kann.

Wieso sollte man die totschweigen und nicht benutzen?

Ach komm, die Diskussion wurde so oft geführt, das muß jetzt nicht auch noch hier sein. Wenn du wirklich über das Für und Wider zu Checked Exceptions streiten willst, mache bitte einen neuen Thread auf.

DEvent schrieb:

Besser als dann das Programm sich beendet, weil man eine Exception vergessen hat zu fangen

Wieso sollte es sich dann beenden Zumindest meine Programme haben in der Message-Pump einen unkonditionellen Exception-Handler. Wenn eine unerwartete Exception fliegt, wird die aktuelle Operation abgebrochen, ggf. ein Dialog für das Senden eines Bug-Reports angezeigt, und dann kanns weitergehen.

DEvent schrieb:

Wie kann man eigentlich const-correctnes von C++ gut finden, aber Checked Excpetions schlecht?

Ganz hervorragende Frage für einen neuen Thread.

[µngbd]

Z schrieb:

Für jemanden, der den Funktionsbegriff aus dem Mathematikunterricht kennt, kann das, was in C++ als Funktion bezeichnet wird, auf den ersten Blick irreführend sein.

Das dürfte der Grund sein, warum zumindest eine Sprache (Scheme) alle diese Dinger pauschal "procedures" nennt.

Gerade fällt mir wieder ein, dass ich in der Schule mit Visual Basic gefoltert wurde, wo man manchmal Klammern um die Argumente machen muss (wenn man den Wert verwendet) und manchmal nicht (wenn nicht). Wahnsinn, sowas. Ist das noch so?

[uio]

audacia schrieb:

DEvent schrieb:

Besser als dann das Programm sich beendet, weil man eine Exception vergessen hat zu fangen

Wieso sollte es sich dann beenden Zumindest meine Programme haben in der Message-Pump einen unkonditionellen Exception-Handler. Wenn eine unerwartete Exception fliegt, wird die aktuelle Operation abgebrochen, ggf. ein Dialog für das Senden eines Bug-Reports angezeigt, und dann kanns weitergehen.

Das ist ja mal richtig undefiniert und gefährlich.