noch ein ganz gnaz kleines *g* zum Wochenende

[ole]

Moinmoin

Da sucht man auf der Homepage der Arbeitsamtes nach Fortbildungsmöglichkeiten und findet in einer Kursbeschreibung folgende Zeile:

"Erlernen von 2 höheren Programmiersprachen: Java, HTML"

Wenn das nicht zum Abrollen ist, dann weiss ichs auch nicht *fg*
Ich glaube nicht das ich mich bei diesem Unternehmen Fortbilden will ;).

Alles Liebe
Ole
(8-)>

[CaptainSolo]

"Erlernen von 2 höheren Programmiersprachen: Java, HTML"

Also gegen Java gibt es denke ich nix einzuwenden.
Aber HTML eine höhere Programmiersprache?!?!

LOL

Gruss,
CS

[LanX]

Hoi

"Erlernen von 2 höheren Programmiersprachen: Java, HTML"

Ich vermute die Wahrheit ist viel skuriler und sie meinten Javascript!

:)
Rolf

[Pascal R.]

Aber HTML eine höhere Programmiersprache?!?!

Höher als Word auf jeden Fall...

P.

[Blau]

Moinmoin

moinmoin

"Erlernen von 2 höheren Programmiersprachen: Java, HTML"

höher = höhers niveau = einfacher

also völlig korrekt

hochniveau sprachen sind sowas vie basic, qbasic, pascal usw...
niedrigniveau sprachen sind sowas wie assembler und evtl C/C++

Wenn das nicht zum Abrollen ist, dann weiss ichs auch nicht *fg*
Ich glaube nicht das ich mich bei diesem Unternehmen Fortbilden will ;).

na, viel spass beim rollen

gruss
Blau

[Ingomar Wesp]

Gruess' Euch,

"Erlernen von 2 höheren Programmiersprachen: Java, HTML"

höher = höhers niveau = einfacher

Hmmm... Ich dachte immer "hoeher" bedeutet bei einer Programmiersprache groessere Abstraktion von der Hardware, sowie die Entfernung von klassischen Merkmalen der funktionalen / prozeduralen Programmierung, also z.B. Modellierung von Klassen in der Objekt-orientierten Programmierung.

also völlig korrekt

Ja, nur ist HTML _beim besten Willen nicht_ eine Programmiersprache, oder hast du schon mal eine HTML-Instruktion / einen HTML-Befehl gesehen?

hochniveau sprachen sind sowas vie basic, qbasic, pascal usw...
niedrigniveau sprachen sind sowas wie assembler und evtl C/C++

Hmmblmblm... C > "Niedrigniveau" > Okay, C++ > "Niedrigniveau" > ???

Vielleicht bin ich ja am falschen Dampfer, wenn ja, sollte ich dringend nochmal nachlesen,

Viele Gruesse jedenfalls,
--- Ingomar Wesp

[Blau]

hallo,

Hmmm... Ich dachte immer "hoeher" bedeutet bei einer Programmiersprache groessere Abstraktion von der Hardware, sowie die Entfernung von klassischen Merkmalen der funktionalen / prozeduralen Programmierung, also z.B. Modellierung von Klassen in der Objekt-orientierten Programmierung.

da hast du wohl vollkommen recht, ich konnte es nur nicht so gut ausdrücken :)

Ja, nur ist HTML _beim besten Willen nicht_ eine Programmiersprache, oder hast du schon mal eine HTML-Instruktion / einen HTML-Befehl gesehen?

stimmt auch, obwohl es viele für eine prog.sprache halten...

Hmmblmblm... C > "Niedrigniveau" > Okay, C++ > "Niedrigniveau" > ???

dazu kann ich auch nur sagen : ??? (was meisnt du damit ?)

Vielleicht bin ich ja am falschen Dampfer, wenn ja, sollte ich dringend nochmal nachlesen,

Viele Gruesse jedenfalls,
--- Ingomar Wesp

ja, auf jedenfall,
gruss
Blau

[Ingomar Wesp]

hallo,

Hmmblmblm... C > "Niedrigniveau" > Okay, C++ > "Niedrigniveau" > ???

dazu kann ich auch nur sagen : ??? (was meisnt du damit ?)

Ich kenn' mich da nicht wirklich allzugut aus, aber so weit ich weiss,
ist C++ einerseits zu C kompatibel, erlaubt also jede Menge Lowlevel-Kostrukte, andererseits ermoeglicht es aber auch recht saubere Objekt-orientierte Programmierung (wenn man nur will).

Man kann also sowohl extreme Pointer-Arithmetik zelebrieren, als auch schoen Strukturierten, flexiblen und damit wiederverwendbaren Code schreiben, also z.B. fein abgeschottete Klassen mit wild wucherndem Innenleben definieren, von dem man aber nicht viel mitkriegt, wenn man denn nicht reinguckt.

Hoffe, das klaert das auf.

Einen wunderschoenen Abend noch,
--- Ingomar Wesp

[Blau]

Hallo (hm.. sven hat recht !)

Ich kenn' mich da nicht wirklich allzugut aus, aber so weit ich weiss,
ist C++ einerseits zu C kompatibel, erlaubt also jede Menge Lowlevel-Kostrukte, andererseits ermoeglicht es aber auch recht saubere Objekt-orientierte Programmierung (wenn man nur will).

Man kann also sowohl extreme Pointer-Arithmetik zelebrieren, als auch schoen Strukturierten, flexiblen und damit wiederverwendbaren Code schreiben, also z.B. fein abgeschottete Klassen mit wild wucherndem Innenleben definieren, von dem man aber nicht viel mitkriegt, wenn man denn nicht reinguckt.

Hoffe, das klaert das auf.

achso... ne ich hatte C/C++ nur drin in meiner "aufzählung", weil viele meinen es sei hochniveau, und andere behaupten es sei niedrigniveau. IMHO kann man da keine klare grenze ziehen, und ich finde es wäre merkwürdig zu sagen dass NUR assembler niedrigniveau ist. naja.

Einen wunderschoenen Abend noch,
--- Ingomar Wesp

dir auch,
Blau

[Frank Schönmann]

hi!

IMHO kann man da keine klare grenze ziehen, und ich finde es wäre
merkwürdig zu sagen dass NUR assembler niedrigniveau ist. naja.

Ist aber so. "Höhere Programmiersprache" bedeutet, dass die Sprache
hardwareunabhängig ist. Und abgesehen von Maschinencode und Assembler
ist das eigentlich jede Sprache.

Und das, was Ingomar da mit "funktionaler" Programmierung bezeichnet
hat, ist eigentlich imperative Programmierung. Funktionale Program-
mierung ist was ganz anderes.

Und jetzt lieber EOT, bevor ihr noch was sagt, was euch später leid
tut... ;)

bye, Frank!

[Ingomar Wesp]

Hallo Genossen,

Und jetzt lieber EOT, bevor ihr noch was sagt, was euch später leid
tut... ;)

Mir ist's nicht peinlich, wenn vielleicht spaeter jeder Einblick in Aeusserungen von mir bekommt, die von Unwissenheit zeugen. Was sollte mir also leid tun? Meiner Auffassung nach lebt man (mitunter), um zu lernen.

Und das, was Ingomar da mit "funktionaler" Programmierung bezeichnet
hat, ist eigentlich imperative Programmierung. Funktionale Program-
mierung ist was ganz anderes.

Meiner Auffassung nach - kann mich freilich auch taueschen - bedeutet funktionale (bzw. prozedurale) Programmierung, dass es moeglich ist Codestuecke zu Funktionen bzw. Prozeduren zusammenzufassen (der Unterschied zwischen den beiden ist, dass Funktionen ueber einen Rueckgabewert verfuegen, also z.B. Algorithmen zur Berechnung verschiedenster Sachen beeinhalten, waehrend Prozeduren zur Ausfuehrung bestimmter Instruktionen bestimmt sind).

"Imperative Programmierung" stelle ich mir als eine lineare Abfolge von auszufuehrenden Instruktionen vor, bei der jedoch Spruenge im Kontrollfluss moeglich sind (Ich glaub' in Basic war das mit "GOTO"  oder so moeglich). Liege ich da richtig?

Funktionale Programmierung ist also - sollte ich sie richtig verstehen - fuer mich "niedriger" als Objekt-orientierte Programmierung und "hoeher" als "Imperative Programmierung", weil man bei der OOP noch weiter geht und Klassen definiert, die Funktionen, Prozeduren und freilich auch Variablen beeinhalten koennen, von denen (den Klassen) man dann Objekte ableiten bzw. instanzieren kann etc. OOP ist also noch ein Stueckchen weiter weg von der Maschine selbst und ein wenig naeher an der Modellvorstellung, die der Entwickler vielleicht hat. Jedenfalls ist sie klarer gegliedert.

Deshalb verstehe ich OOP als das "hoechste" unter den oben genannten Modellen und dafuer auch stark Kennzeichnend fuer eine Hochsprache. Vielleicht ist das aber auch Quatsch. Jedenfalls ist der erste Teil meiner Definition (Abstraktion von Hardware) auch deiner Auffassung nach richtig, der zweite falsch, weil... (bitte ankreuzen)

[ ] Es völlig egal ist, ob "imperativ", funktional, Objekt-orientiert oder sonstwas, hauptsache weit weg von der Hardware.

[ ] Auch funktionale Programmierung bereits eine Hochsprache auszeichnet.

[ ] ... (bitte ausfuellen)

Es wuerde mich wirklich interessieren.
Vielen Dank und viel Spass noch,
--- Ingomar Wesp

[Michael Schröpl]

Hi Ingomar,

Meiner Auffassung nach - kann mich freilich auch taueschen - bedeutet
funktionale (bzw. prozedurale) Programmierung, dass es moeglich ist
Codestuecke zu Funktionen bzw. Prozeduren zusammenzufassen

Das würde auch ich "prozedurale" (oder eher "modulare") Programmierung
nennen.

Ich würde "funktionale Programmierung" dort ansiedeln, wo ich eine Sprache
verwende, die _nur_ Funktionen und Verzweigungen kann, aber beispielsweise
keine Schleifen. Such mal nach Begriffen wie "primitiv rekursiv" - ich ver-
mute, Du wirst im Umfeld von LISP landen.

(der Unterschied zwischen den beiden ist, dass Funktionen ueber einen
Rueckgabewert verfuegen, also z.B. Algorithmen zur Berechnung verschie-
denster Sachen beeinhalten, waehrend Prozeduren zur Ausfuehrung bestimm-
ter Instruktionen bestimmt sind).

Dieser Unterschied ist aber trivial und irrelevant.
Jede Prozedur läßt sich immer auch als Funktion darstellen.

"Imperative Programmierung" stelle ich mir als eine lineare Abfolge von
auszufuehrenden Instruktionen vor, bei der jedoch Spruenge im Kontroll-
fluss moeglich sind (Ich glaub' in Basic war das mit "GOTO"  oder so
moeglich). Liege ich da richtig?

Auch einen Schleife würde in meinen Augen noch dazu gehören.
Deren Realisierung ist auch nur ein (bedingter) Sprung, genau wie das GOTO.
Ein Funktionsaufruf dagegen ist etwas qualitativ Anderes - er öffnet eine
neue Verarbeitungsebene. Denke beispielsweise an die lokalen Variablen,
die dabei implizit entstehen.

Funktionale Programmierung ist also - sollte ich sie richtig verstehen

• fuer mich "niedriger" als Objekt-orientierte Programmierung und
  "hoeher" als "Imperative Programmierung", weil man bei der OOP noch
  weiter geht und Klassen definiert, die Funktionen, Prozeduren und
  freilich auch Variablen beeinhalten koennen, von denen (den Klassen)
  man dann Objekte ableiten bzw. instanzieren kann etc.
  OOP ist also noch ein Stueckchen weiter weg von der Maschine selbst
  und ein wenig naeher an der Modellvorstellung, die der Entwickler
  vielleicht hat. Jedenfalls ist sie klarer gegliedert.

Mag sein. Ich selbst tue mich an dieser Stelle schwer, zwischen den
verschiedenen Sorten der 3GL irgend eine Art von Hierarchie zu erkennen.
Vernünftig modular zu programmieren kommt der Objektorientierung halt
schon sehr nahe.

der zweite falsch, weil... (bitte ankreuzen)
[ ] Es völlig egal ist, ob "imperativ", funktional, Objekt-orientiert
    oder sonstwas, hauptsache weit weg von der Hardware.

Alle diese Sprachen sind Sprachen der 3. Generation.
Assembler ist 2GL; SQL und reguläre Ausdrücke sind 4GL, Prolog soll sogar
5GL sein, habe ich gerade auf
   http://www.techfak.uni-bielefeld.de/ags/wbski/lehre/digiSA/Gedankengeschichte/Vortrag18052001/generationen.html
als Beispiel gesehen.

[ ] Auch funktionale Programmierung bereits eine Hochsprache auszeichnet.

Verglichen mit einer 2GL, ja.

[ ] ... (bitte ausfuellen)

Es wuerde mich wirklich interessieren.

Die "Höhe" einer Sprache würde ich an ihrer Generation festmachen.
(Und nein, eine höhere Sprache ist _nicht_ automatisch leichter zu
_lernen_ als eine "niedrigere" - sie ist nur leichter zu beherrschen.)

Es gibt allerdings unterschiedliche Methoden, Generationen zu definieren.
Deine Beschreibung paßt beispielsweise ziemlich gut zu
   http://www.dwp42.org/public/oop_plc/tabelle1.htm,
während meine Vorstellung eher in Richtung
   http://www.ifi.unibas.ch/ifi/studies/lectures/informatik1/archiv/lekt_4/sld007.htm
geht.

Viele Grüße
      Michael

[Frank Schönmann]

hi!

Mal schauen, ob ich mitten in der Nacht noch was verständliches auf
die Reihe bringen kann... ,)

Und das, was Ingomar da mit "funktionaler" Programmierung
bezeichnet hat, ist eigentlich imperative Programmierung.
Funktionale Programmierung ist was ganz anderes.
Meiner Auffassung nach - kann mich freilich auch taueschen -
bedeutet funktionale (bzw. prozedurale) Programmierung, dass es
moeglich ist Codestuecke zu Funktionen bzw. Prozeduren
zusammenzufassen (der Unterschied zwischen den beiden ist, dass
Funktionen ueber einen Rueckgabewert verfuegen, also z.B.
Algorithmen zur Berechnung verschiedenster Sachen beeinhalten,
waehrend Prozeduren zur Ausfuehrung bestimmter Instruktionen
bestimmt sind).

Mal ein bisschen aufräumen: Prozeduren sind eigentlich, wie Michael
schon angedeutet hat, lediglich Funktionen ohne Rückgabewert -- oder
Funktionen sind Prozeduren mit Rückgabewert. Jedenfalls kann man die
einen auf die anderen abbilden.

Funktionale Programmierung bedeutet in der Tat, dass man Funktionen
aufruft und dann deren Rückgabewerte weiterverwendet. Aber unter
reiner funktionaler Programmierung versteht man etwas anderes, da
man in imperativen Sprachen, die Funktionen unterstützen -- wie C,
Pascal, und fast alle anderen imp. Sprachen -- auch andere Paradigmen
findet.

Reine funktionale Programmiersprachen haben daneben (normalerweise)
noch die folgenden typischen Eigenschaften:
 * referential transparancy: jeder Ausdruck hat zu jedem Zeitpunkt
   der Ausführung den gleichen Wert, da es keine Nebenwirkungen gibt.
 * Funktionen höherer Ordnung: quasi Funktionen als Parameter einer
   anderen Funktion.
 * lazy evaluation: Auswertung eines Ausdrucks bei Bedarf.

Ansonsten kann man funktionale Sprachen noch nach allen möglichen
Kriterien kategorisieren. Typischerweise sind Sprachen für die
Anwendung von Mathematik-Programmen wie Mathematica funktionale
Sprachen. Bekannt ist dann noch LISP und Scheme, vielleicht auch
Miranda oder Haskell.

"Imperative Programmierung" stelle ich mir als eine lineare
Abfolge von auszufuehrenden Instruktionen vor, bei der jedoch
Spruenge im Kontrollfluss moeglich sind (Ich glaub' in Basic war
das mit "GOTO"  oder so moeglich). Liege ich da richtig?

Ja, das trifft es ziemlich genau. Allerdings ist der Aufruf anderer
Funktionen auch lediglich ein Sprung im Kontrollfluss. Imperative
Programmierung bedeutet dann, dass die Instruktionen deines Programms
genau in der Reihenfolge ausgeführt werden, wie du es in deinem
Programm festgelegt hast. Ein wichtiger Unterschied zur oben
genannten "lazy evaluation". Außerdem wird dadurch auch (indirekt)
die "referential transparancy" ausgehebelt, da du jetzt zb. den
Wert von Variablen ändern kannst im Laufe des Programms.

Funktionale Programmierung ist also - sollte ich sie richtig
verstehen - fuer mich "niedriger" als Objekt-orientierte
Programmierung und "hoeher" als "Imperative Programmierung",

Das sind unterschiedliche Dinge, die man so nicht vergleichen kann,
da es sich um verschiedene Paradigmen handelt.

OOP ist also noch ein Stueckchen weiter weg von der Maschine
selbst und ein wenig naeher an der Modellvorstellung, die der
Entwickler vielleicht hat. Jedenfalls ist sie klarer gegliedert.

Funktionale Programmierung hat sehr viel mit Mathematik zu tun -- zb.
sind Funktionen in der Mathematik auch werttreu und müssen erst bei
Bedarf berechnet werden. Daher ist die funktionale Programmierung
ein völlig anderer Ansatz zur Problemlösung als OOP.

Deshalb verstehe ich OOP als das "hoechste" unter den oben
genannten Modellen und dafuer auch stark Kennzeichnend fuer eine
Hochsprache. Vielleicht ist das aber auch Quatsch. Jedenfalls ist
der erste Teil meiner Definition (Abstraktion von Hardware) auch
deiner Auffassung nach richtig, der zweite falsch, weil... (bitte
ankreuzen)

Abstraktion von der Hardware ist IMHO das einzige Kriterium für eine
Hochsprache... :)

Um Michaels Link weiterzuführen. Hier ist eine nette Unterscheidung
zwischen verschiedenen Paradigmen für Programmiersprachen:
  http://www.techfak.uni-bielefeld.de/ags/wbski/lehre/digiSA/Gedankengeschichte/Vortrag18052001/paradig.html
Und meiner Meinung nach ist die Kategorisierung nach Paradigmen die
brauchbarste für Programmiersprachen, da die Einteilung in xGLs
IMHO etwas schwammig ist.

bye, Frank!

[LanX]

Hi Ingomar

Der begriff 'höhere Programmiersprachen' stammt aus einer Zeit in der man
C und Cobol usw von Assembler unterscheiden wollte, ist also IMHO nicht
auf spätere Entwicklungen übertragbar, so dass man "noch höhere" Programmier-
sprachen erkennen möchte. Der Denkfehler ist dabei "neuer" mit "höher"
zu verwechseln, im Glauben Neuerungen würden linear aufeinander aufbauen.

Wie du den beiden anderen Antworten entnehmen kannst gibts viele verschiedene
und _unabhängige_ Einzelaspekte, wie "lokale Variablen", "lazy evaluation"
usw die hinzukommen, die die Klassifizierung der Sprachen nur in
mehrdimensionalen Skalen zuläßt. Wie will man da nun eine "Höhe" ableiten?

Z.B. ich bin sicher dass man auch OOP ohne Funktionen nur mit GOTOs
realisieren könnte, zu dem Zeitpunkt als OOP sich durchsetzte waren aber
Funktionen allgemeingut.

Deine Begriff höhere Programmiersprache ist heutzutage eigentlich
veraltet, hält sich aber hartnäckig weil er sich gut anhört. Das hat
mehr mit Psychologie und Marketing zu tun als mit konkretem Bedarf!

Tschau
Rolf

PS: Die assembler die ich kenne hatten alle auch subroutinen gekannt,
sind das nun halbhohe funktionale Programmiersprachen? ;-)