info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Morgen kommt die "Corona Warn-App" - hier ist der Code
4 views
Skip to first unread message
Thomas Koenig
Jun 15, 2020, 10:09:16 AM6/15/20
to
Helmut Wabnig <hwabnig@> schrieb:
> BASIC ist auch die beste Programiersprache,
> weil es einen GOTO Befehl gibt.
COMEFROM ist viel besser, siehe "A Linguistic Contribution of
GOTO-less Programming", DATAMATION, December, 1973,
Oder halt, wie beim OS/360 FORTRAN IV G - Compiler implementiert,
als AT - Statement.
Dagegen ist BASIC Kinderkram.
> BASIC ist auch die beste Programiersprache,
> weil es einen GOTO Befehl gibt.
COMEFROM ist viel besser, siehe "A Linguistic Contribution of
GOTO-less Programming", DATAMATION, December, 1973,
Oder halt, wie beim OS/360 FORTRAN IV G - Compiler implementiert,
als AT - Statement.
Dagegen ist BASIC Kinderkram.
Volker N. Englisch
Jun 15, 2020, 12:33:06 PM6/15/20
to
In de.comp.lang.misc Thomas Koenig <tko...@netcologne.de> wrote:
> Helmut Wabnig <hwabnig@> schrieb:
>
>> BASIC ist auch die beste Programiersprache,
>> weil es einen GOTO Befehl gibt.
Gibts in COBOL und RPG (sic!) auch. Sogar in Pascal.
> Helmut Wabnig <hwabnig@> schrieb:
>
>> BASIC ist auch die beste Programiersprache,
>> weil es einen GOTO Befehl gibt.
> COMEFROM ist viel besser, siehe "A Linguistic Contribution of
> GOTO-less Programming", DATAMATION, December, 1973,
> Oder halt, wie beim OS/360 FORTRAN IV G - Compiler implementiert,
> als AT - Statement.
> Dagegen ist BASIC Kinderkram.
Jep.
Thomas Koenig
Jun 15, 2020, 2:01:06 PM6/15/20
to
Volker N. Englisch <vne...@rrzli.de> schrieb:
FORTRAN IV ist nach heutigen Gesichtspunkten natürlich stark
veraltet. Stammt aber auch von 1962.
Seit 1991 ist Fortran Fortran allerdings eine moderne
Programmiersprache mit ziemlich vielen Möglichkeiten, mittlereweile
hat die Sprache derived types (=structs in C), automatische
Übergabe von Arraygrenzen, dynamische Speicherwerwaltung,
Array-Ausdrücke, Module, Objektorientierung und Parallelisierung
(partitionaed global address space, über Coarrays).
Und mehrdimensionale Arrays konnte Fortran II im Jahr 1958 schon
besser als C heute...
veraltet. Stammt aber auch von 1962.
Seit 1991 ist Fortran Fortran allerdings eine moderne
Programmiersprache mit ziemlich vielen Möglichkeiten, mittlereweile
hat die Sprache derived types (=structs in C), automatische
Übergabe von Arraygrenzen, dynamische Speicherwerwaltung,
Array-Ausdrücke, Module, Objektorientierung und Parallelisierung
(partitionaed global address space, über Coarrays).
Und mehrdimensionale Arrays konnte Fortran II im Jahr 1958 schon
besser als C heute...
Juergen Ilse
Jun 15, 2020, 3:01:22 PM6/15/20
to
Hallo,
Wie wir spaetestens seit dem Artikel "real programmers don't use pascal"
wissen, hat in Fortran auch das arithmetische "IF" (das mit den drei
Ausgaengen) so einiges fuer sich (weil es Programme interessanter macht).
;-)
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
wissen, hat in Fortran auch das arithmetische "IF" (das mit den drei
Ausgaengen) so einiges fuer sich (weil es Programme interessanter macht).
;-)
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Thomas Koenig
Jun 16, 2020, 2:42:54 AM6/16/20
to
Juergen Ilse <ne...@usenet-verwaltung.de> schrieb:
"hatte" ist vielleicht etwas präziser, seit 1991 ist es "obsolecent",
seit 2018 aus der Norm verschwunden.
Ich habe mir mal "Abstracting Away The Machine" besorgt, die Geschichte
von Fortran. Das ist absolut faszinierend, wie es aussah, als das Team
von Backus damals mit dem ersten Fortran-Compiler angefangen hat.
Damals haben die meisten Programmier Maschinensprache geschrieben.
Wenige haben Assembler verwendet, das hat wertvolle Maschinenzeit
verbraten und war für Weicheier. (Never mind the debugging).
Und der erste Fortran-Compiler hat es tatsächlich hinbekommen,
die Effizienz von handgeschriebenem Maschinen- bzw. Assemblercode
zu erreichen.
Das Team hat damals den basic block erfunden (einschließlich
reordering) und mit (wie wir heute sagen würden) strength
reduction, value propagation und dead code elimination operiert.
Die Registerzuteilung war auch exzellent (da hat man erst Jahrzehnte
später was besseres gefunden). Ein weiterer riesiger Schritt
war arithmetisch korrektes Parsen von Formeln wie a + b*c**(d+e),
allerdings viel komplizierter als heute (ohne Rekursion).
Und das alles in ca. 24000 Assembler-Instruktionen für den
ganzen Compiler, auf einer Maschine mit einem Akkumulator,
einem Hilfsregister und drei Indexregistern.
Die Leute hatten's echt drauf.
seit 2018 aus der Norm verschwunden.
Ich habe mir mal "Abstracting Away The Machine" besorgt, die Geschichte
von Fortran. Das ist absolut faszinierend, wie es aussah, als das Team
von Backus damals mit dem ersten Fortran-Compiler angefangen hat.
Damals haben die meisten Programmier Maschinensprache geschrieben.
Wenige haben Assembler verwendet, das hat wertvolle Maschinenzeit
verbraten und war für Weicheier. (Never mind the debugging).
Und der erste Fortran-Compiler hat es tatsächlich hinbekommen,
die Effizienz von handgeschriebenem Maschinen- bzw. Assemblercode
zu erreichen.
Das Team hat damals den basic block erfunden (einschließlich
reordering) und mit (wie wir heute sagen würden) strength
reduction, value propagation und dead code elimination operiert.
Die Registerzuteilung war auch exzellent (da hat man erst Jahrzehnte
später was besseres gefunden). Ein weiterer riesiger Schritt
war arithmetisch korrektes Parsen von Formeln wie a + b*c**(d+e),
allerdings viel komplizierter als heute (ohne Rekursion).
Und das alles in ca. 24000 Assembler-Instruktionen für den
ganzen Compiler, auf einer Maschine mit einem Akkumulator,
einem Hilfsregister und drei Indexregistern.
Die Leute hatten's echt drauf.
F. W.
Jun 16, 2020, 3:37:54 AM6/16/20
to
schon ein paar BASIC-Programme geschrieben. Wenigstens auf der /390 :-D
FW
Thomas Koenig
Jun 16, 2020, 4:45:16 AM6/16/20
to
[F'up]
F. W. <m...@home.com> schrieb:
>> aber normalerweise braucht man ihn eher selten.
>
> Ja, ich habe ihn in meinen professionellen Jahren nur ein einziges mal
> benutzt (Druckroutinen der IBM Anlagenbuchhaltung - als Vorsicht!).
Ich verwende goto in C in zwei Fällen: Entweder um aus inneren
Schleifen rauszukommen (da es im Gegensatz zu anderen Sprachen kein
"break label" gibt), oder für Fehlerbehandlung bei fatalen Fehlern
im Sinne von
if (fataler_fehler_1)
{
rc = FATAL_1;
goto raushier;
}
...
if (fataler_fehler_2)
{
rc = FATAL_2;
goto raushier;
}
/* Wenn wir hier ankommen, dann haben wir einen Fatalen Fehler (TM);
foo und bar muessen nocht gefrobniziert werden. */
raushier:
...
return rc;
}
Das Problem beim goto ist ja nicht der Befehl selber, sondern der
Zustand, in dem das Programm sich befindet, wenn es beim Label
ankommt.
F. W. <m...@home.com> schrieb:
> Am 16.06.2020 um 09:07 schrieb Carla Schneider:
>
>>> BASIC ist auch die beste Programiersprache, weil es einen GOTO
>>> Befehl gibt.
>
>> Es gibt in C auch einen goto Befehl, wenn man ihn braucht ist er da,
>
>>> BASIC ist auch die beste Programiersprache, weil es einen GOTO
>>> Befehl gibt.
>
>> aber normalerweise braucht man ihn eher selten.
>
> Ja, ich habe ihn in meinen professionellen Jahren nur ein einziges mal
> benutzt (Druckroutinen der IBM Anlagenbuchhaltung - als Vorsicht!).
Ich verwende goto in C in zwei Fällen: Entweder um aus inneren
Schleifen rauszukommen (da es im Gegensatz zu anderen Sprachen kein
"break label" gibt), oder für Fehlerbehandlung bei fatalen Fehlern
im Sinne von
if (fataler_fehler_1)
{
rc = FATAL_1;
goto raushier;
}
...
if (fataler_fehler_2)
{
rc = FATAL_2;
goto raushier;
}
/* Wenn wir hier ankommen, dann haben wir einen Fatalen Fehler (TM);
foo und bar muessen nocht gefrobniziert werden. */
raushier:
...
return rc;
}
Das Problem beim goto ist ja nicht der Befehl selber, sondern der
Zustand, in dem das Programm sich befindet, wenn es beim Label
ankommt.
F. W.
Jun 16, 2020, 5:35:20 AM6/16/20
to
Am 16.06.2020 um 10:45 schrieb Thomas Koenig:
> Das Problem beim goto ist ja nicht der Befehl selber, sondern der
> Zustand, in dem das Programm sich befindet, wenn es beim Label
> ankommt.
Genau: ich kam nämlich nicht mehr raus :->
> Das Problem beim goto ist ja nicht der Befehl selber, sondern der
> Zustand, in dem das Programm sich befindet, wenn es beim Label
> ankommt.
FW
Markus Franzke
Jun 16, 2020, 5:44:30 AM6/16/20
to
Am 16.06.20 um 10:45 schrieb Thomas Koenig:
> Ich verwende goto in C in zwei Fällen: Entweder um aus inneren
> Schleifen rauszukommen (da es im Gegensatz zu anderen Sprachen kein
> "break label" gibt), oder für Fehlerbehandlung bei fatalen Fehlern
> im Sinne von
>
> if (fataler_fehler_1)
> {
> rc = FATAL_1;
> goto raushier;
> }
>
> ...
>
> if (fataler_fehler_2)
> {
> rc = FATAL_2;
> goto raushier;
> }
>
> /* Wenn wir hier ankommen, dann haben wir einen Fatalen Fehler (TM);
> foo und bar muessen nocht gefrobniziert werden. */
> raushier:
> ...
> return rc;
> }
>
> Das Problem beim goto ist ja nicht der Befehl selber, sondern der
> Zustand, in dem das Programm sich befindet, wenn es beim Label
> ankommt.
>
Viel geiler sind longjmp() und setjmp().
M.
> Ich verwende goto in C in zwei Fällen: Entweder um aus inneren
> Schleifen rauszukommen (da es im Gegensatz zu anderen Sprachen kein
> "break label" gibt), oder für Fehlerbehandlung bei fatalen Fehlern
> im Sinne von
>
> if (fataler_fehler_1)
> {
> rc = FATAL_1;
> goto raushier;
> }
>
> ...
>
> if (fataler_fehler_2)
> {
> rc = FATAL_2;
> goto raushier;
> }
>
> /* Wenn wir hier ankommen, dann haben wir einen Fatalen Fehler (TM);
> foo und bar muessen nocht gefrobniziert werden. */
> raushier:
> ...
> return rc;
> }
>
> Das Problem beim goto ist ja nicht der Befehl selber, sondern der
> Zustand, in dem das Programm sich befindet, wenn es beim Label
> ankommt.
>
M.
Thomas Koenig
Jun 16, 2020, 10:16:21 AM6/16/20
to
F. W. <m...@home.com> schrieb:
Noch traumatisiert, weil die Jobs nicht losliefen wegen zu niedriger
Prio? :-)
Lochkartenstapel abgeben und am nächsten Tag wiederkommen kann es
ja kaum gewesen sein auf einer /390, da war die Zeit eigentlich
schon vorbei :-)
Prio? :-)
Lochkartenstapel abgeben und am nächsten Tag wiederkommen kann es
ja kaum gewesen sein auf einer /390, da war die Zeit eigentlich
schon vorbei :-)
Juergen Ilse
Jun 16, 2020, 5:39:03 PM6/16/20
to
Thomas Koenig <tko...@netcologne.de> wrote:
> Juergen Ilse <ne...@usenet-verwaltung.de> schrieb:
die "entry" Anweisung verschwunden, und man kann keine "alternativen Ein-
sprungpunktein Unterprogramme" mehr definieren?
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
> Juergen Ilse <ne...@usenet-verwaltung.de> schrieb:
>> In de.comp.lang.misc Thomas Koenig <tko...@netcologne.de> wrote:
>>> Helmut Wabnig <hwabnig@> schrieb:
>>>> BASIC ist auch die beste Programiersprache,
>>>> weil es einen GOTO Befehl gibt.
>>> COMEFROM ist viel besser, siehe "A Linguistic Contribution of
>>> GOTO-less Programming", DATAMATION, December, 1973,
>>> Oder halt, wie beim OS/360 FORTRAN IV G - Compiler implementiert,
>>> als AT - Statement.
>>> Dagegen ist BASIC Kinderkram.
>> Wie wir spaetestens seit dem Artikel "real programmers don't use pascal"
>> wissen, hat in Fortran auch das arithmetische "IF" (das mit den drei
>> Ausgaengen) so einiges fuer sich (weil es Programme interessanter macht).
> "hatte" ist vielleicht etwas präziser, seit 1991 ist es "obsolecent",
> seit 2018 aus der Norm verschwunden.
Ja, die Sprache wird immermehr verstuemmelt ... Isst vielleicht auch schon
>>> Helmut Wabnig <hwabnig@> schrieb:
>>>> BASIC ist auch die beste Programiersprache,
>>>> weil es einen GOTO Befehl gibt.
>>> COMEFROM ist viel besser, siehe "A Linguistic Contribution of
>>> GOTO-less Programming", DATAMATION, December, 1973,
>>> Oder halt, wie beim OS/360 FORTRAN IV G - Compiler implementiert,
>>> als AT - Statement.
>>> Dagegen ist BASIC Kinderkram.
>> Wie wir spaetestens seit dem Artikel "real programmers don't use pascal"
>> wissen, hat in Fortran auch das arithmetische "IF" (das mit den drei
>> Ausgaengen) so einiges fuer sich (weil es Programme interessanter macht).
> "hatte" ist vielleicht etwas präziser, seit 1991 ist es "obsolecent",
> seit 2018 aus der Norm verschwunden.
die "entry" Anweisung verschwunden, und man kann keine "alternativen Ein-
sprungpunktein Unterprogramme" mehr definieren?
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
F. W.
Jun 17, 2020, 3:55:38 AM6/17/20
to
Am 16.06.2020 um 16:16 schrieb Thomas Koenig:
>>> Dagegen ist BASIC Kinderkram.
>> ...wenn der FORTRAN-Compiler mal läuft, schon. In der Zeit hast Du aber
>> schon ein paar BASIC-Programme geschrieben. Wenigstens auf der /390 :-D
> Noch traumatisiert, weil die Jobs nicht losliefen wegen zu niedriger
> Prio? :-)
> Lochkartenstapel abgeben und am nächsten Tag wiederkommen kann es
> ja kaum gewesen sein auf einer /390, da war die Zeit eigentlich
> schon vorbei :-)
Ja, wir Studis waren immer das Letzte. :-D
>>> Dagegen ist BASIC Kinderkram.
>> ...wenn der FORTRAN-Compiler mal läuft, schon. In der Zeit hast Du aber
>> schon ein paar BASIC-Programme geschrieben. Wenigstens auf der /390 :-D
> Noch traumatisiert, weil die Jobs nicht losliefen wegen zu niedriger
> Prio? :-)
> Lochkartenstapel abgeben und am nächsten Tag wiederkommen kann es
> ja kaum gewesen sein auf einer /390, da war die Zeit eigentlich
> schon vorbei :-)
FW
Thomas Koenig
Jun 17, 2020, 5:21:49 AM6/17/20
to
F. W. <m...@home.com> schrieb:
Also, in der Zeit, in der ich in Karlsruhe an der Großrechneranlage
(Siemens 7881 mit MVS-Clone von Fujitsu) einen Studentenaccount
hatte, hatte ich da keine Probleme.
Bloß die CPU-Zeit war sehr knapp (reichte aber für LaTeX, als
damals auf einem 286er eine Seite eine Minute brauchte), und vor
allem gab es da einen LASERDRUCKER! Unglaublich!
(Siemens 7881 mit MVS-Clone von Fujitsu) einen Studentenaccount
hatte, hatte ich da keine Probleme.
Bloß die CPU-Zeit war sehr knapp (reichte aber für LaTeX, als
damals auf einem 286er eine Seite eine Minute brauchte), und vor
allem gab es da einen LASERDRUCKER! Unglaublich!
F. W.
Jun 17, 2020, 8:17:43 AM6/17/20
to
Am 17.06.2020 um 11:21 schrieb Thomas Koenig:
> Also, in der Zeit, in der ich in Karlsruhe an der Großrechneranlage
> (Siemens 7881 mit MVS-Clone von Fujitsu) einen Studentenaccount
> hatte, hatte ich da keine Probleme.
Ich war froh, als die Pflichtzeit vorbei war und wir uns zwischen einer
> Also, in der Zeit, in der ich in Karlsruhe an der Großrechneranlage
> (Siemens 7881 mit MVS-Clone von Fujitsu) einen Studentenaccount
> hatte, hatte ich da keine Probleme.
HP3000 (Cobol) und einer Nixdorf Quattro (C) entscheiden durften. Die
Quattro hatte ich lieb gewonnen (wie vorher die 8870) aber die wurde
damals schon abgebaut, um einer HPUX-Maschine Platz zu machen.
Die 8870 war eine geile BASIC-Maschine. Extrem pragmatisch aufgebaut,
flott und mit COMET ein Standard, leider aber schlunzig dokumentiert.
Viele Unterroutinen waren gar nicht bekannt, so dass ich in den USA
recherchieren durfte.
> Bloß die CPU-Zeit war sehr knapp (reichte aber für LaTeX, als damals
> auf einem 286er eine Seite eine Minute brauchte), und vor allem gab
> es da einen LASERDRUCKER! Unglaublich!
FW
Juergen Ilse
Jun 17, 2020, 9:51:42 AM6/17/20
to
Hallo,
Thomas Koenig <tko...@netcologne.de> wrote:
> Also, in der Zeit, in der ich in Karlsruhe an der Großrechneranlage
> (Siemens 7881 mit MVS-Clone von Fujitsu) einen Studentenaccount
> hatte, hatte ich da keine Probleme.
Mitte der 80er wurden die Programmieraufgaben der Anfaegervorlesung program-
mieren in Pascal auf der Cyber durchgefuehrt: Erzeugen des Lochkartenstapels
und Stapel abgeben, amnaechsten Tag den Ausdruck abholen. Auf dem Ausdruck
waren dann wahlweise diie Compilerfehlermeldungen oder die Ausgabe des
Programms.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Thomas Koenig <tko...@netcologne.de> wrote:
> Also, in der Zeit, in der ich in Karlsruhe an der Großrechneranlage
> (Siemens 7881 mit MVS-Clone von Fujitsu) einen Studentenaccount
> hatte, hatte ich da keine Probleme.
mieren in Pascal auf der Cyber durchgefuehrt: Erzeugen des Lochkartenstapels
und Stapel abgeben, amnaechsten Tag den Ausdruck abholen. Auf dem Ausdruck
waren dann wahlweise diie Compilerfehlermeldungen oder die Ausgabe des
Programms.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Thomas Koenig
Jun 17, 2020, 4:45:01 PM6/17/20
to
Juergen Ilse <ne...@usenet-verwaltung.de> schrieb:
per quasi-Assembler gemacht, sondern über eine Masterfunktion.
D.h.so was wie
SUBROUTINE FOO(A)
REAL A
A = 1.0
ENTRY BAR(I)
INTEGER I
I = 1
wird dann zu
subroutine foo(a)
real :: a
call foo_master(1, a=a)
end
subroutine bar(i)
real :: i
call foo_master (2, i=i)
end
subroutine foo_master (num_routine, a, i)
integer, intent(in) :: num_routine
real, optional :: a
integer, optional :: i
if (num_routine <= 1) then
a = 1.0
end if
if (num_routine <= 2) then
i = 1
end if
end subroutine foo_master
(Die Syntax stimmt nicht ganz).
Kriegt man also auch ganz gut so hin.
>>> Wie wir spaetestens seit dem Artikel "real programmers don't use pascal"
>>> wissen, hat in Fortran auch das arithmetische "IF" (das mit den drei
>>> Ausgaengen) so einiges fuer sich (weil es Programme interessanter macht).
>> "hatte" ist vielleicht etwas präziser, seit 1991 ist es "obsolecent",
>> seit 2018 aus der Norm verschwunden.
>
> Ja, die Sprache wird immermehr verstuemmelt ... Isst vielleicht auch schon
> die "entry" Anweisung verschwunden, und man kann keine "alternativen Ein-
> sprungpunktein Unterprogramme" mehr definieren?
Das wird mittlerweile in moderen Fortran - Programmen nicht mehr
>>> wissen, hat in Fortran auch das arithmetische "IF" (das mit den drei
>>> Ausgaengen) so einiges fuer sich (weil es Programme interessanter macht).
>> "hatte" ist vielleicht etwas präziser, seit 1991 ist es "obsolecent",
>> seit 2018 aus der Norm verschwunden.
>
> Ja, die Sprache wird immermehr verstuemmelt ... Isst vielleicht auch schon
> die "entry" Anweisung verschwunden, und man kann keine "alternativen Ein-
> sprungpunktein Unterprogramme" mehr definieren?
per quasi-Assembler gemacht, sondern über eine Masterfunktion.
D.h.so was wie
SUBROUTINE FOO(A)
REAL A
A = 1.0
ENTRY BAR(I)
INTEGER I
I = 1
wird dann zu
subroutine foo(a)
real :: a
call foo_master(1, a=a)
end
subroutine bar(i)
real :: i
call foo_master (2, i=i)
end
subroutine foo_master (num_routine, a, i)
integer, intent(in) :: num_routine
real, optional :: a
integer, optional :: i
if (num_routine <= 1) then
a = 1.0
end if
if (num_routine <= 2) then
i = 1
end if
end subroutine foo_master
(Die Syntax stimmt nicht ganz).
Kriegt man also auch ganz gut so hin.
0 new messages