Würfeln mit Armin

[Rainer Weikusat]

Perl-Implementierung eines auf Facebook veröffentlichten Algorithmus'
zur Ermittlung von Armin Laschets Forderungen zur Corona-Politik.

NB: Ich habe mir das gestern mal schnell geschrieben, weil ich die Idee
witzig fand ohne mir groß Gedanken darüber zu machen, wie sinnvoll oder
verständlich der Code ist.

«Was wir jetzt brauchen ist ein vierhebiger intransparenter Ehrenstopp
bis in die Puppen zur sofortigen Halbierung der Bundesklanzlerin.»

----------
#!/usr/bin/perl
#
# "wuerfeln mit Armin"
#

use utf8;
use open qw(:std :utf8);

my @steps = (
'Was wir jetzt brauchen ist ein/e',
['ein-', 'zwei-', 'drei-', 'vier-', 'fünf-', 'sechs-'],
[qw(tägige/r wöchige/r monatige/r fache/r malige/r hebige/r)],
[qw(harte/r softe/r optionale/r intransparente/r alternativelose/r unumkehrbare/r)],
[qw(Wellenbrecher- Brücken- Treppen- Wende- Impf- Ehren-)],
[qw(Lockdown:m Stopp:m Maßnahme:w Kampagne:w Sprint:m Matrix:w)],
'bis',
['zum Sommer', 'auf Weiteres', 'zur Bundestagswahl', '2030', 'nach den Abiturprüfungen', 'in die Puppen'],
'zur',
[qw(sofortigen nachhaltigen allmählichen unausweichlichen wirtschaftsschonenden willkürlichen)],
[qw(Senkung Steigerung Beendigung Halbierung Vernichtung Beschönigung)],
'der',
['Infektionszahlen', 'privaten Treffen', 'Wirtschaftsleistung', 'Wahlprognosen', 'dritten Welle', 'Bundesklanzlerin']);

sub roll
{
return int(rand(6));
}

sub step
{
my $step;

$step = $steps[$_];
return ref($step) ? $$step[roll()] : $step;
}

sub cnct
{
my ($last, @out);

for (@_) {
if (/(.+)-$/) {
$last .= $1;
next;
}

$_ = $last.lcfirst($_) if $last;

push(@out, $_);
$last = undef;
}

return @out;
}

sub mw
{
my (@mw, @out);

for (@_) {
if (/(.+\/(e|r))/) {
push(@out, $1);
push(@mw, $#out);

next;
}

if (/(.+):(m|w)$/) {
push(@out, $1);

if ($2 eq 'm') {
for (@mw) {
$out[$_] =~ s/\/e$//;
$out[$_] =~ s/\/r$/r/;
}
} else {
for (@mw) {
$out[$_] =~ s/\/e$/e/;
$out[$_] =~ s/\/r$//;
}
}

@mw = ();

next;
}

push(@out, $_);
}

return @out;
}

my @prg = mw(cnct(map { &step } 0 .. $#steps));

print(join(' ', @prg), ".\n");

[Christian Hanné]

Perl is out, Pyhton ist angesagt.

[Rainer Weikusat]

Christian Hanné <the....@gmail.com> writes:
> Perl is out, Pyhton ist angesagt.

Python ist was für Legastheniker :-)

[Thomas Zajic]

* Rainer Weikusat <rwei...@talktalk.net>

> Christian Hanné <the....@gmail.com> writes:
> > Perl is out, Pyhton ist angesagt.
>
> Python ist was für Legastheniker :-)

Nein, das verwechselst du jetzt mit Phyton. Oder war das Pytohn? :-P
--
=-------------------------------------------------------------------------=
- Thomas "ZlatkO" Zajic <zla...@gmx.at> Linux-5.10 & slrn-1.0.2 -
=-------------------------------------------------------------------------=

[Christian Schumacher]

Thomas Zajic schrieb:

| User-Agent: slrn/1.0.3 (Linux)

> --
> [...] Linux-5.10 & slrn-1.0.2 -

Deine Sig braucht ein Update ;-)

--
Gruß
Christian

»Ausnahmen beschädigen die Regel.«

[Thomas Zajic]

* Christian Schumacher <cs....@nurfuerspam.de>

> Deine Sig braucht ein Update ;-)

Oops, hoppla, danke für den Hinweis! Wie konnte *das* denn nur passieren?
Liegt bestimmt an dieser schwindelerregenden Releasefrequenz, kein Wunder
daß man da mit dem Updaten der Signatur nicht mehr hinterherkommt ... :-D

> slrn-1.0.3a.tar.bz2, creation date: 2016-10-24T09:12:38 [GMT]
> old/slrn-1.0.2.tar.bz2, creation date: 2014-09-20T02:12:26 [GMT]

(von http://jedsoft.org/releases/slrn/)

LG,
Tho "look mum, new signature!" mas
--
=-------------------------------------------------------------------------=
- Thomas "ZlatkO" Zajic <zla...@gmx.at> Linux-5.10 & slrn-1.0.3 -
=-------------------------------------------------------------------------=

[Juergen Ilse]

Bei anderen Sprachen hat es Jahrzehnte gekostet, um Syntax und Formatierung
(sinnvollerweise) zu trennen. Bei Python hat man genau diesen Unsinn dann
wieder eingefuehrt ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Rainer Weikusat]

Juergen Ilse <ne...@usenet-verwaltung.de> writes:
> Rainer Weikusat <rwei...@talktalk.net> wrote:
>> Christian Hanné <the....@gmail.com> writes:
>>> Perl is out, Pyhton ist angesagt.
>>
>> Python ist was für Legastheniker :-)
>
> Bei anderen Sprachen hat es Jahrzehnte gekostet, um Syntax und Formatierung
> (sinnvollerweise) zu trennen. Bei Python hat man genau diesen Unsinn dann
> wieder eingefuehrt ...

Grundsätzlich stimme ich dem zu: Der Gedanke, unsichtbare Zeichen
semantisch relevant zu machen, ist bizarr. Zumal Python deswegen
keineswegs ohne Begrenzungszeichen auskommt: Nach einem Ausdruck in
einem Schleifen- oder Verzweigungsanweisung muß ein : stehen. Einziger
Zweck davon ist, daß man trotz der einrückungsbasierten Syntax 'kurze'
Schleifen oder Verzweigungen auf eine Zeile schreiben kann.

Da bin ich einige Male drüber gestolpert, als ich soviel Python lernen
mußte, um in nicht trivialem Code (bitbake) ein paar notwendige
Änderungen machen zu können.

Andererseits verstehe ich aber auch die Motivation dahinter: Viele Leute
benutzten zum Code-schreiben «Primitivwerkzeuge», die keine automatische
Einrückung können und sind außerdem auch viel zu faul, um über
konsistente Formatierung auch nur nachzudenken. Mit so geschriebenem Code
habe ich schon gearbeitet: Das gibt ein wildes Durcheinander
inkonsistent angewendeter persönlicher Formatierungsstile (wenn genügend
Leute daran arbeiten) und bevor man da durchblickt, ist es im
allgemeinen sinnvoll, alles erstmal automatisch konsistent formatieren
zu lassen. Da gibt es dann wiederum Leute, die viel zu ängstlich wären,
um an einem evtl großen Haufen unverständlichen Codes irgendwas zu
ändern. Wer kann schon sagen, das dann passieren wird!

Diesem Chaos dadurch effektiv einen Riegel vorzuschieben, daß man eine
lesbare Formatierung als Seiteneffekt syntaktischer Notwendigkeiten
bekommt, kann einem wie ein Geniestreich vorkommen. Jedenfalls löst es
mal ein Problem. Bringt natürlich wenig, weil die Chaoten immer noch
chaotischen Code schreiben, aber wenigstens sieht er nett aus :-).

Gibt's übrigens noch einem besser: YAML (XML reloaded, sozuagen, da
weder les- noch parsebar). Dort werden sowohl Einrückungen als auch
geklammerte Blöcke für dieselben semantischen Konstrukte benutzt.

ZB:

vektor:
- 0
- 1
- 2
- 3

identisch zu (aus dem Kopf)

vektor: [0, 1,
2, 3
]

Natürlich gibt es Leute, die vollkommen überzeugt sind, beide
"Formationen" müßten unterschiedliches bedeuten, weil sie doch
unterschiedlich aussehen.

[Marc 'BlackJack' Rintsch]

On Wed, 07 Apr 2021 18:10:19 +0200, Christian Hanné wrote:

> Perl is out, Pyhton ist angesagt.

```
#!/usr/bin/env python3
import random
import re

STEPS = [
["Was wir jetzt brauchen ist ein/e"],

["ein-", "zwei-", "drei-", "vier-", "fünf-", "sechs-"],

["tägige/r", "wöchige/r", "monatige/r", "fache/r", "malige/r", "hebige/r"],
[
"harte/r",
"softe/r",
"optionale/r",
"intransparente/r",
"alternativelose/r",
"unumkehrbare/r",
],
["Wellenbrecher-", "Brücken-", "Treppen-", "Wende-", "Impf-", "Ehren-"],
[
"Lockdown:m",
"Stopp:m",
"Maßnahme:w",
"Kampagne:w",
"Sprint:m",
"Matrix:w",

],
["bis"],
[
"zum Sommer",
"auf Weiteres",
"zur Bundestagswahl",
"2030",
"nach den Abiturprüfungen",
"in die Puppen",

],
["zur"],
[
"sofortigen",
"nachhaltigen",
"allmählichen",
"unausweichlichen",
"wirtschaftsschonenden",
"willkürlichen",
],
[
"Senkung",
"Steigerung",
"Beendigung",
"Halbierung",
"Vernichtung",
"Beschönigung",

],
["der"],
[
"Infektionszahlen",
"privaten Treffen",
"Wirtschaftsleistung",
"Wahlprognosen",
"dritten Welle",

"Bundesklanzlerin",
],
]


def concat(parts):
previous_part = ""
for part in parts:
if part.endswith("-"):
previous_part += part[:-1]
else:
if previous_part:
part = previous_part + part.lower()
yield part
previous_part = ""


def fixup_sex(parts):
result = []
indices_to_fix = []
for part in parts:
if re.search(r"\/[er]$", part):
indices_to_fix.append(len(result))
else:
match = re.fullmatch(r"(?P<part>.+):(?P<sex>[mw])", part)
if match:
part = match["part"]
keep = {"m": "r", "w": "e"}[match["sex"]]
for index in indices_to_fix:
part_to_fix = result[index]
result[index] = part_to_fix[:-2] + (
keep if part_to_fix.endswith(keep) else ""
)
indices_to_fix = []

result.append(part)

return result


def main():
print(" ".join(fixup_sex(concat(map(random.choice, STEPS)))), end=".\n")


if __name__ == "__main__":
main()
```

Ciao,
Marc 'BlackJack' Rintsch
--
“C is quirky, flawed, and an enormous success.“ -- Dennis M. Ritchie

[Dietrich Clauss]

Rainer Weikusat wrote:
> Juergen Ilse <ne...@usenet-verwaltung.de> writes:
>> Rainer Weikusat <rwei...@talktalk.net> wrote:
>>> Christian Hanné <the....@gmail.com> writes:
>>>> Perl is out, Pyhton ist angesagt.
>>>
>>> Python ist was für Legastheniker :-)
>>
>> Bei anderen Sprachen hat es Jahrzehnte gekostet, um Syntax und Formatierung
>> (sinnvollerweise) zu trennen. Bei Python hat man genau diesen Unsinn dann
>> wieder eingefuehrt ...
>
> Grundsätzlich stimme ich dem zu: Der Gedanke, unsichtbare Zeichen
> semantisch relevant zu machen, ist bizarr.

Was heißt hier 'unsichtbare Zeichen'? Eine Einrückung ist sehr wohl
sichtbar. Eine Einrückung bzw. deren Fehlen sticht sogar regelrecht ins
Auge, was man von einer (fehlenden) Klammer oder einem (fehlenden)
'begin' nicht behaupten kann.

> Zumal Python deswegen
> keineswegs ohne Begrenzungszeichen auskommt: Nach einem Ausdruck in
> einem Schleifen- oder Verzweigungsanweisung muß ein : stehen. Einziger
> Zweck davon ist, daß man trotz der einrückungsbasierten Syntax 'kurze'
> Schleifen oder Verzweigungen auf eine Zeile schreiben kann.
>
> Da bin ich einige Male drüber gestolpert, als ich soviel Python lernen
> mußte, um in nicht trivialem Code (bitbake) ein paar notwendige
> Änderungen machen zu können.
>
> Andererseits verstehe ich aber auch die Motivation dahinter: Viele Leute
> benutzten zum Code-schreiben «Primitivwerkzeuge», die keine automatische
> Einrückung können und sind außerdem auch viel zu faul, um über
> konsistente Formatierung auch nur nachzudenken. Mit so geschriebenem Code
> habe ich schon gearbeitet:

So geschriebener Code ist nicht die Motivation dahinter.

> Das gibt ein wildes Durcheinander
> inkonsistent angewendeter persönlicher Formatierungsstile (wenn genügend
> Leute daran arbeiten) und bevor man da durchblickt, ist es im
> allgemeinen sinnvoll, alles erstmal automatisch konsistent formatieren
> zu lassen. Da gibt es dann wiederum Leute, die viel zu ängstlich wären,
> um an einem evtl großen Haufen unverständlichen Codes irgendwas zu
> ändern. Wer kann schon sagen, das dann passieren wird!
>
> Diesem Chaos dadurch effektiv einen Riegel vorzuschieben, daß man eine
> lesbare Formatierung als Seiteneffekt syntaktischer Notwendigkeiten
> bekommt, kann einem wie ein Geniestreich vorkommen. Jedenfalls löst es
> mal ein Problem.

Es /ist/ ein Geniestreich. Ja, den Doppelpunkt hätte man auch noch
einsparen können, und man hätte festlegen sollen, daß zum Einrücken
/genau/ /ein/ /Tab/ verwendet wird. Aber das kommt vielleicht noch.
Die Entwicklung der Sprache ist schließlich noch nicht zu Ende.

> Bringt natürlich wenig, weil die Chaoten immer noch
> chaotischen Code schreiben, aber wenigstens sieht er nett aus :-).

Chaotischer Code ist ein Totschlagargument, d.h. kein Argument. Der
Python-Ansatz bringt dort genauso wenig wie automatische
Formatierungstools bei anderen Sprachen.

[Juergen Ilse]

Hallo,

Dietrich Clauss <diet...@clauss-it.com> wrote:
> Rainer Weikusat wrote:
>> Juergen Ilse <ne...@usenet-verwaltung.de> writes:
>>> Bei anderen Sprachen hat es Jahrzehnte gekostet, um Syntax und Formatierung
>>> (sinnvollerweise) zu trennen. Bei Python hat man genau diesen Unsinn dann
>>> wieder eingefuehrt ...
>>
>> Grundsätzlich stimme ich dem zu: Der Gedanke, unsichtbare Zeichen
>> semantisch relevant zu machen, ist bizarr.
>
> Was heißt hier 'unsichtbare Zeichen'? Eine Einrückung ist sehr wohl
> sichtbar.

Aber *ein* <TAB> ist optisch nicht von einer entsprechenden Anzahl <BLANKS>
unterschiedbar, hat aber u.U. eine *voellig* *andere* Semantik. So etwas
auch nur fuer eine produktive programmiersprache anzudenken ist *PERVERS*-

> Eine Einrückung bzw. deren Fehlen sticht sogar regelrecht ins
> Auge, was man von einer (fehlenden) Klammer oder einem (fehlenden)
> 'begin' nicht behaupten kann.

Die fehlende Klammer oder das fehlende "begin" oder "end" wird i.d.R.
vom Compiler bemerkt und mit einer entsprechenden Fehlermeldung quittiert
(wenn die Zahl der "begin" und "end" oder die Zahl der oeffnenden und
schliessenden Klammern nicht mehr uebereinstimmt). Der Programmierer
wird sich also (wenn er eienen solchen Fehler eingebaut hat) nach dem
Fehler ssuchen muessen, der python Programmierer hat aber im Fall des
<TAB> kaum eine Chance ...

>> Andererseits verstehe ich aber auch die Motivation dahinter: Viele Leute
>> benutzten zum Code-schreiben «Primitivwerkzeuge», die keine automatische
>> Einrückung können und sind außerdem auch viel zu faul, um über
>> konsistente Formatierung auch nur nachzudenken. Mit so geschriebenem Code
>> habe ich schon gearbeitet:
>
> So geschriebener Code ist nicht die Motivation dahinter.

Das ist aber kein Argument, denn "echte Programmierer koennen in jeder
beliebigen Programmiersprache Fortran Programme schreiben" wie es so
schoen im Artikel "real programmers don't usee pascal" in der deutschen
Ueberseetzung heisst. Oder anders formuliert: Wer nicht an lesbarem Code
interessiert ist, wird auch in jeder noch so "zwanghaften Sprache"
unlesbaren Code schreiben koennen.

>> Diesem Chaos dadurch effektiv einen Riegel vorzuschieben, daß man eine
>> lesbare Formatierung als Seiteneffekt syntaktischer Notwendigkeiten
>> bekommt, kann einem wie ein Geniestreich vorkommen. Jedenfalls löst es
>> mal ein Problem.

... nicht. Leider loest das das Problem keineswegs, es verschiebt es
bestenfalls ein bischen. Einigung ueber zu nutzende Programmier- und
Formatierungsrichtlinien im Team und konsequente Ablehnung von Code,
der nicht diesen Vorgaben entspricht (ggfs. mit entsprechenden dienst-
rechtlichen Konsequenzen) kann da hilfreich sein, und waere auch nicht
so einfach zu unterlaufen.

> Es /ist/ ein Geniestreich.

... mit sehr eigenartiger Auffassung von "Genie". In manchem Sinne ist
auch eine Programmiersprache wie "whitespace" ein "Geniestreich" ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Thomas Koenig]

Juergen Ilse <ne...@usenet-verwaltung.de> schrieb:

> Das ist aber kein Argument, denn "echte Programmierer koennen in jeder
> beliebigen Programmiersprache Fortran Programme schreiben" wie es so
> schoen im Artikel "real programmers don't usee pascal" in der deutschen
> Ueberseetzung heisst.

FORTRAN, bitte.

Fortran ist eine moderne Programmiersprache.

[Dietrich Clauss]

oder vielleicht doch?


```
if True:
pass
pass
```

| $ python3 prog.py
| File "prog.py", line 3
| pass
| ^
| TabError: inconsistent use of tabs and spaces in indentation

Das war jetzt einfach.

[Rainer Weikusat]

Dietrich Clauss <diet...@clauss-it.com> writes:
> Rainer Weikusat wrote:
>> Juergen Ilse <ne...@usenet-verwaltung.de> writes:
>>> Rainer Weikusat <rwei...@talktalk.net> wrote:
>>>> Christian Hanné <the....@gmail.com> writes:
>>>>> Perl is out, Pyhton ist angesagt.
>>>>
>>>> Python ist was für Legastheniker :-)
>>>
>>> Bei anderen Sprachen hat es Jahrzehnte gekostet, um Syntax und Formatierung
>>> (sinnvollerweise) zu trennen. Bei Python hat man genau diesen Unsinn dann
>>> wieder eingefuehrt ...
>>
>> Grundsätzlich stimme ich dem zu: Der Gedanke, unsichtbare Zeichen
>> semantisch relevant zu machen, ist bizarr.
>
> Was heißt hier 'unsichtbare Zeichen'?

[rw@doppelsaurus]/tmp#cat a.c
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(int argc, char **argv)
{
unsigned x;

srand(time(NULL));
x = atoi(argv[1]);
do
putchar(rand() & 1 ? ' ' : '\t');
while (--x);

putchar('\n');

return 0;
}
[rw@doppelsaurus]/tmp#gcc a.c
[rw@doppelsaurus]/tmp#./a.out 50

[rw@doppelsaurus]/tmp#

Ermittle mit bloßem Auge, wieviele Zeichen in der Zeile vor dem letzten
Prompt stehen. :-)

[Rainer Weikusat]

Juergen Ilse <ne...@usenet-verwaltung.de> writes:
> Rainer Weikusat wrote:

[...]

>> Diesem Chaos dadurch effektiv einen Riegel vorzuschieben, daß man eine
>> lesbare Formatierung als Seiteneffekt syntaktischer Notwendigkeiten
>> bekommt, kann einem wie ein Geniestreich vorkommen. Jedenfalls löst es
>> mal ein Problem.
>
> ... nicht. Leider loest das das Problem keineswegs, es verschiebt es
> bestenfalls ein bischen. Einigung ueber zu nutzende Programmier- und
> Formatierungsrichtlinien im Team und konsequente Ablehnung von Code,
> der nicht diesen Vorgaben entspricht (ggfs. mit entsprechenden dienst-
> rechtlichen Konsequenzen) kann da hilfreich sein, und waere auch nicht
> so einfach zu unterlaufen.

Entwicklung wird nicht nur von Konzernen und öffentlichen Einrichtungen
betrieben und in vielen Fällen kann man bei neuen Kollegen schon froh
sein, wenn sie überhaupt Code schreiben können, der wenigstens ungefähr
das tut, was er tun müßte. :-)

[Rainer Weikusat]

Marcus Jodorf <tr...@killfile.de> writes:
> Juergen Ilse <ne...@usenet-verwaltung.de> schrieb:

>> Die fehlende Klammer oder das fehlende "begin" oder "end" wird i.d.R.
>> vom Compiler bemerkt und mit einer entsprechenden Fehlermeldung
>> quittiert (wenn die Zahl der "begin" und "end" oder die Zahl der
>> oeffnenden und schliessenden Klammern nicht mehr uebereinstimmt). Der
>> Programmierer wird sich also (wenn er eienen solchen Fehler eingebaut
>> hat) nach dem Fehler ssuchen muessen, der python Programmierer hat
>> aber im Fall des <TAB> kaum eine Chance ...
>

> Du meinst kaum eine Chance, weil die Fehlermeldung
>
> File „blah“, line xxx
> TabError: inconsistent use of tabs and spaces in indention
>
> bei der Interpretersprache viel zu unmittelbar kommt, während sich beim
> Compiler der Programmierer wenigstens schon mal noch mental drauf
> einstellen kann, während der Compiler erst mal noch rödelt?
>
> Ernsthaft: Das ist Quatsch. Fehlermeldungen haben sie bei python nicht
> abgeschafft und je nach Situation sind die da genauso mal mehr oder
> weniger hilfreich wie bei jeder anderen Sprache auch.
> Du beschreibst da ein Problem, das so nicht wirklich existiert.

Dafür existiert ein anderes Problem: Pythoncode ist
positionsabhängig. Im Prinzip ist jede Codefolge eine manuelle
Einzelanfertigung, die genau an die Programmstelle paßt, wo sie angefügt
wurde. Verschiebt man einen inhaltliche zusammenhängende Codeblock an
eine ander Stelle, muß man die Formatierung manuell richtig anpassen,
damit die Semantik wieder stimmt.

Für Sprachen mit expliziten Blockbegrenzern ist das nicht notwendig: Ein
verschobener Block fügt sich ganz von Selbst in seinen neuern,
übergeordneten Block ein und man kann ihn automatisch «richtig»
formatieren lassen.

[Dietrich Clauss]

Man schiebt den Codeblock an die gewünschte Position, vertikal, und bei
Python eben auch horizontal. Problem gelöst.

[Dietrich Clauss]

Sehr witzig. Wenn jemand eine Syntax erfinden würde, in der /trailing
whitespace/ eine Bedeutung hat[1], wäre das Geschrei ja in gewisser
Weise nachvollziehbar. Das ist bei Python aber gerade nicht der Fall.

- Dietrich

[1] Ja, sowas gibts. Bei LDIF kann man Zeilenumbrüche quoten, indem man
die Folgezeile um genau ein Leerzeichen einrückt. Whitespace am Ende
der aktuellen Zeile geht dann mit ins Ergebnis ein. Dort habe ich mich
auch gefragt, was da geraucht wurde und wie man auf die Idee kommt,
sowas als menschenles- und v.a. schreibbar zu bezeichnen.

[Rainer Weikusat]

Das ist eine Wiederholung eines Teils meines Textes. Natürlich kann man
manuell um diese Sprachdesignproblem herumwürgen.

[Rainer Weikusat]

Wir halten also mal fest, daß ASCII-codes (in diesem Fall), denen keine
Grapheme zugeordnet sind, tatsächlich «unsichtbar» sind (warum auch
immer jemand meinte, daß bestreiten zu müssen). Darum ging es in meiner
Aussage.

Übrigens werden Text nicht dadurch aussagekräftiger, daß man unmotiviert
emotional stark aufgeladene und vollkommen unpassende Begriffe darin
unterbringt (wie «Geschrei»). Das läßt bestenfalls auf einen
Mangel an kommunikativen Fähgkeiten schließen.

[Оlе Ѕtrеісhеr]

Rainer Weikusat <rwei...@talktalk.net> writes:
>>> Dafür existiert ein anderes Problem: Pythoncode ist
>>> positionsabhängig. Im Prinzip ist jede Codefolge eine manuelle
>>> Einzelanfertigung, die genau an die Programmstelle paßt, wo sie angefügt
>>> wurde. Verschiebt man einen inhaltliche zusammenhängende Codeblock an
>>> eine ander Stelle, muß man die Formatierung manuell richtig anpassen,
>>> damit die Semantik wieder stimmt.
>>>
>>> Für Sprachen mit expliziten Blockbegrenzern ist das nicht notwendig: Ein
>>> verschobener Block fügt sich ganz von Selbst in seinen neuern,
>>> übergeordneten Block ein und man kann ihn automatisch «richtig»
>>> formatieren lassen.
>>
>> Man schiebt den Codeblock an die gewünschte Position, vertikal, und bei
>> Python eben auch horizontal. Problem gelöst.
>
> Das ist eine Wiederholung eines Teils meines Textes. Natürlich kann man
> manuell um diese Sprachdesignproblem herumwürgen.

Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
das Reformat wird der Code schnell unlesbar.

Und das ist ein generelles Problem mit C, Java & Co: es gibt keinerlei
Vorschriften, wie eine bestimmte Programmstruktur visuell dargestellt
wird -- bzw. es gibt genügend davon, sodas sich jeder seine ganz eigene
aussuchen kann. Dagegen hat Python einen Großteil der Formatierung schon
in die Sprache selbst gesteckt, und einen weiteren Teil in PEP-8. Das
sorgt für eine standardisierte Darstellung des Codes, die bei der
Einarbeitung in fremden (professionellen) Code sehr hilfreich ist.

Dagegen kocht in C jeder sein eigenes Süppchen. Wenn an in mehr als
einem Projekt arbeitet, muss man daher jedesmal neu überlegen, wie eine
gewisse Programmstruktur visuell dargestellt wird. Einer schnellen
Einarbeitung ist das eher nicht zuträglich.

Meines Erachtens hat das was mit dem Selbstverständnis der Entwickler
zum Zeitpunkt der Sprachentwicklung zu tun: in den 70/80ern (C) sahen
sie sich als hochkreative Leute, denen möglichst wenig Schranken
auferlegt werden sollten. Und solange Software auch von Einzelpersonen
bzw. kleinen festen Teams entwickelt wurde, war das ja auch OK.

Heute hat man es dagegen mit Entwicklungen zu tun, die von vielen
Einzelpersonen getragen werden -- hunderte Entwickler sind bei großen
Projekten nicht unüblich. Von denen tragen aber viele nur einige Zeilen
Code bei. Damit das klappt, müssen sich diese Leute schnell in den Code
einarbeiten können, und da hilft eine weitgehend eindeutige Formatierung
ungemein; selbst dann wenn sie nicht perfekt den eigenen Vorstellungen
entspricht.

Ole

[Rainer Weikusat]

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Rainer Weikusat <rwei...@talktalk.net> writes:
>>>> Dafür existiert ein anderes Problem: Pythoncode ist
>>>> positionsabhängig. Im Prinzip ist jede Codefolge eine manuelle
>>>> Einzelanfertigung, die genau an die Programmstelle paßt, wo sie angefügt
>>>> wurde. Verschiebt man einen inhaltliche zusammenhängende Codeblock an
>>>> eine ander Stelle, muß man die Formatierung manuell richtig anpassen,
>>>> damit die Semantik wieder stimmt.
>>>>
>>>> Für Sprachen mit expliziten Blockbegrenzern ist das nicht notwendig: Ein
>>>> verschobener Block fügt sich ganz von Selbst in seinen neuern,
>>>> übergeordneten Block ein und man kann ihn automatisch «richtig»
>>>> formatieren lassen.
>>>
>>> Man schiebt den Codeblock an die gewünschte Position, vertikal, und bei
>>> Python eben auch horizontal. Problem gelöst.
>>
>> Das ist eine Wiederholung eines Teils meines Textes. Natürlich kann man
>> manuell um diese Sprachdesignproblem herumwürgen.
>
> Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
> das Reformat wird der Code schnell unlesbar.

In C muß man vor allem nie «neu formatieren», denn es gibt Werkzeuge, die
das automatisch erledigen. Das ist mit Python grundsätzlich nicht
möglich. Das ist aber mehr ein Nebenaspekt (obwohl es natürlich beim
Arbeiten mit existierenden Code vollkommen vermeidbare Mehrarbeit
verursacht).

Das Problem ist, daß der Inhalt eines zusammenhängende Quellcodeblocks
semantisch von allen äußeren Quellcodeblöcken abhängig ist. Damit ist er
grundsätzlich kein «strukturiertes» Programmkonstrukt mehr.

> Und das ist ein generelles Problem mit C, Java & Co: es gibt keinerlei
> Vorschriften, wie eine bestimmte Programmstruktur visuell dargestellt
> wird -- bzw. es gibt genügend davon, sodas sich jeder seine ganz eigene
> aussuchen kann. Dagegen hat Python einen Großteil der Formatierung schon
> in die Sprache selbst gesteckt, und einen weiteren Teil in PEP-8. Das
> sorgt für eine standardisierte Darstellung des Codes, die bei der
> Einarbeitung in fremden (professionellen) Code sehr hilfreich ist.

Entgegen von Lieblingsannahmem der Whitespace-Sammler ist die
Formatierung von Code zur Einarbeitung in ihn vollkommen unerheblich
(außer in Python, natürlich, wo sie eine zusätzliche Komplikation
darstellt) oder - um genauer zu sagen - wenn der Code so trivial ist,
daß sein Inhalt sich ohne eine gründliche Analyse erschließt, dann ist
die Formatierung auch vollkommen egal.

[rw@doppelsaurus]~#perl <<TT
print 1
TT
[rw@doppelsaurus]~#
[rw@doppelsaurus]~#perl <<TT
print 1
TT
1[rw@doppelsaurus]~#perl <<TT
[rw@doppelsaurus]~#perl <<TT
> print
>
>
>
> 1
> TT
1[rw@doppelsaurus]~#

wird beides niemandem Rätsel aufgeben.

[Оlе Ѕtrеісhеr]

Rainer Weikusat <rwei...@talktalk.net> writes:
> Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
>> Rainer Weikusat <rwei...@talktalk.net> writes:
>>>>> Dafür existiert ein anderes Problem: Pythoncode ist
>>>>> positionsabhängig. Im Prinzip ist jede Codefolge eine manuelle
>>>>> Einzelanfertigung, die genau an die Programmstelle paßt, wo sie angefügt
>>>>> wurde. Verschiebt man einen inhaltliche zusammenhängende Codeblock an
>>>>> eine ander Stelle, muß man die Formatierung manuell richtig anpassen,
>>>>> damit die Semantik wieder stimmt.
>>>>>
>>>>> Für Sprachen mit expliziten Blockbegrenzern ist das nicht notwendig: Ein
>>>>> verschobener Block fügt sich ganz von Selbst in seinen neuern,
>>>>> übergeordneten Block ein und man kann ihn automatisch «richtig»
>>>>> formatieren lassen.
>>>>
>>>> Man schiebt den Codeblock an die gewünschte Position, vertikal, und bei
>>>> Python eben auch horizontal. Problem gelöst.
>>>
>>> Das ist eine Wiederholung eines Teils meines Textes. Natürlich kann man
>>> manuell um diese Sprachdesignproblem herumwürgen.
>>
>> Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
>> das Reformat wird der Code schnell unlesbar.
>
> In C muß man vor allem nie «neu formatieren», denn es gibt Werkzeuge, die
> das automatisch erledigen. Das ist mit Python grundsätzlich nicht
> möglich. Das ist aber mehr ein Nebenaspekt (obwohl es natürlich beim
> Arbeiten mit existierenden Code vollkommen vermeidbare Mehrarbeit
> verursacht).

Das gibt es auch in Python. Es ist ja wirklich nur die richtige
Einrückung, und das macht mein Emacs mit C-c > bzw. C-c < . Eventuell
mit M-q für den passenden Zeilenumbruch. Über den dazu nötigen
Zeitaufwand zu reden ist ein wenig müßig, zumal man ja sofort *sieht*,
ob der Codeblock korrekt eingerückt ist.

> Das Problem ist, daß der Inhalt eines zusammenhängende Quellcodeblocks
> semantisch von allen äußeren Quellcodeblöcken abhängig ist. Damit ist er
> grundsätzlich kein «strukturiertes» Programmkonstrukt mehr.

Der Inhalt eines "Blocks" ist in Python auch unabhängig vom Rest. Nur
die Einbindung in die Umgebung hängt von der Einrückung ab.

Sicher lassen sich da Ausnahmen finden, aber die bastele ich Dir im
Notfall auch für C zusammen.

>> Und das ist ein generelles Problem mit C, Java & Co: es gibt keinerlei
>> Vorschriften, wie eine bestimmte Programmstruktur visuell dargestellt
>> wird -- bzw. es gibt genügend davon, sodas sich jeder seine ganz eigene
>> aussuchen kann. Dagegen hat Python einen Großteil der Formatierung schon
>> in die Sprache selbst gesteckt, und einen weiteren Teil in PEP-8. Das
>> sorgt für eine standardisierte Darstellung des Codes, die bei der
>> Einarbeitung in fremden (professionellen) Code sehr hilfreich ist.
>
> Entgegen von Lieblingsannahmem der Whitespace-Sammler ist die
> Formatierung von Code zur Einarbeitung in ihn vollkommen unerheblich
> (außer in Python, natürlich, wo sie eine zusätzliche Komplikation
> darstellt) oder - um genauer zu sagen - wenn der Code so trivial ist,
> daß sein Inhalt sich ohne eine gründliche Analyse erschließt, dann ist
> die Formatierung auch vollkommen egal.

Ich kann hier nur aus Erfahrung mit der Maintainance von diversen
Debian-Paketen reden, die sowohl Python als auch C, C++, Java, Fortran
und einiges andere umfassen. Und ich bin lange genug dabei, keine Angst
vor irgendeiner Sprache zu haben (sagen wir mal: außer Perl). Trotzdem
sind mir die Pythonprojekte am liebsten; einfach weil ich dort innerhalb
von Minuten klarkomme und Fixes propagieren kann, wenn ich einen Fehler
finde.

Das liegt sicher nicht nur an der starken visuellen Standardisierung von
Pythoncode, aber das ist (subjektiv) einer der Gründe.

Ole

[Stefan Reuther]

Am 30.04.2021 um 16:50 schrieb Ole Streicher:
> Rainer Weikusat <rwei...@talktalk.net> writes:

>> Ole Streicher <ole-use...@gmx.net> writes:
>>> Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
>>> das Reformat wird der Code schnell unlesbar.
>>
>> In C muß man vor allem nie «neu formatieren», denn es gibt Werkzeuge, die
>> das automatisch erledigen. Das ist mit Python grundsätzlich nicht
>> möglich. Das ist aber mehr ein Nebenaspekt (obwohl es natürlich beim
>> Arbeiten mit existierenden Code vollkommen vermeidbare Mehrarbeit
>> verursacht).
>
> Das gibt es auch in Python. Es ist ja wirklich nur die richtige
> Einrückung, und das macht mein Emacs mit C-c > bzw. C-c < . Eventuell
> mit M-q für den passenden Zeilenumbruch.

Für C, C++, Perl, Shell, Pascal, JavaScript reicht einmal Tab.

Bei Python ist der Code nach dem Tab meistens kaputt.

Das ist halt einfach Redundanz. Die hilft ansonsten auch z.B. Code durch
kaputte Mailer zu bringen (war Google nicht mal so ein
Whitespace-Fresser?). Und: wenn der Code nach Tab falsch aussieht, fehlt
irgendwo ein Semikolon oder eine Klammer.

> Trotzdem sind mir die Pythonprojekte am liebsten; einfach weil ich
> dort innerhalb von Minuten klarkomme und Fixes propagieren kann, wenn
> ich einen Fehler finde.
>
> Das liegt sicher nicht nur an der starken visuellen Standardisierung von
> Pythoncode, aber das ist (subjektiv) einer der Gründe.

Die meisten anderen Sprachen sind auch visuell halbwegs standardisiert.
Klar, es gibt 1TBS vs. Allman vs. GNU, aber wenn's um's lesen geht,
macht das keinen Unterschied.

Da ist eher relevant, ob meine müden Augen mit 2er Einrückung gefordert
werden oder entspannte 4 oder 8 vorgesetzt bekommen. *Das* Problem hat
Python aber auch. Sogar noch mehr, weil ein "springe zur passenden
schließenden Klammer" (M-C-f / M-C-b) fehlt.

Aber am Ende würde es nicht mehrere Sprachen geben, wenn es nicht
mehrere Geschmäcker gäbe. Objektorientierung macht in Python irgendwie
mehr Spaß als in Perl.


Stefan

[Оlе Ѕtrеісhеr]

Stefan Reuther <stefa...@arcor.de> writes:
> Am 30.04.2021 um 16:50 schrieb Ole Streicher:
>> Rainer Weikusat <rwei...@talktalk.net> writes:
>>> Ole Streicher <ole-use...@gmx.net> writes:
>>>> Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
>>>> das Reformat wird der Code schnell unlesbar.
>>>
>>> In C muß man vor allem nie «neu formatieren», denn es gibt Werkzeuge, die
>>> das automatisch erledigen. Das ist mit Python grundsätzlich nicht
>>> möglich. Das ist aber mehr ein Nebenaspekt (obwohl es natürlich beim
>>> Arbeiten mit existierenden Code vollkommen vermeidbare Mehrarbeit
>>> verursacht).
>>
>> Das gibt es auch in Python. Es ist ja wirklich nur die richtige
>> Einrückung, und das macht mein Emacs mit C-c > bzw. C-c < . Eventuell
>> mit M-q für den passenden Zeilenumbruch.
>
> Für C, C++, Perl, Shell, Pascal, JavaScript reicht einmal Tab.

Aber nur, wenn der Editor entsprechend den Regeln der entsprechenden
Entwicklergemeinde eingerichtet ist. Und da unterscheidet sich mein
Editor von den meisten Regeln der von mir betreuten Pakete an der einen
oder anderen Stelle.

> Bei Python ist der Code nach dem Tab meistens kaputt.

Das passiert mir eigentlich nie.

> Das ist halt einfach Redundanz. Die hilft ansonsten auch z.B. Code durch
> kaputte Mailer zu bringen (war Google nicht mal so ein
> Whitespace-Fresser?).

Mailtexte sind als Codeverteiler generell nicht wirklich geeignet. Und
in Anhängen passiert das eher selten. Ich bin mir auch nicht sicher, ob
man eine Programmiersprache nach Bugs in einigen Mailprogrammen
ausrichten sollte.

> Und: wenn der Code nach Tab falsch aussieht, fehlt irgendwo ein
> Semikolon oder eine Klammer.

Wenn der Code visuell nicht die von mir intendierte Struktur
widerspiegelt, dann ist da irgendwas falsch. Auch ohne Semikolons oder
Klammern.

>> Trotzdem sind mir die Pythonprojekte am liebsten; einfach weil ich
>> dort innerhalb von Minuten klarkomme und Fixes propagieren kann, wenn
>> ich einen Fehler finde.
>>
>> Das liegt sicher nicht nur an der starken visuellen Standardisierung von
>> Pythoncode, aber das ist (subjektiv) einer der Gründe.
>
> Die meisten anderen Sprachen sind auch visuell halbwegs standardisiert.
> Klar, es gibt 1TBS vs. Allman vs. GNU, aber wenn's um's lesen geht,
> macht das keinen Unterschied.

Meine Erfahrung: es macht einen Unterschied. Gerade wenn man schnell
einen Überblick bekommen möchte, ist eine hochstandardisierte
Formatierung sehr hilfreich.

> Da ist eher relevant, ob meine müden Augen mit 2er Einrückung gefordert
> werden oder entspannte 4 oder 8 vorgesetzt bekommen. *Das* Problem hat
> Python aber auch.

Nicht mit PEP-8.

> Sogar noch mehr, weil ein "springe zur passenden schließenden Klammer"
> (M-C-f / M-C-b) fehlt.

Das hätte ich manchmal auch gerne; es stellt aber eher ein
Implementations- als ein prinzipielles Problem dar. Emacs müsste ja
einfach an die letzte Codezeile mit mindestens der passenden Einrückung
springen.

> Aber am Ende würde es nicht mehrere Sprachen geben, wenn es nicht
> mehrere Geschmäcker gäbe. Objektorientierung macht in Python irgendwie
> mehr Spaß als in Perl.

Nun hängen Programmiersprachen eben heutzutage nicht mehr so stark vom
persönlichen "Geschmack" ab, sondern von kollektiven Entscheidungen.

Ole

[Bonita Montero]

> Aber *ein* <TAB> ist optisch nicht von einer entsprechenden Anzahl <BLANKS>
> unterschiedbar, hat aber u.U. eine *voellig* *andere* Semantik. So etwas
> auch nur fuer eine produktive programmiersprache anzudenken ist *PERVERS*-

So kann das nur ein Mensch mit gestörtem Sicherheitsgefühl sehen,
und so einer bist Du. Wenn man aber eine richtige IDE nimmt, die
IDEs für Python werden sicher Tabs sein lassen, dann ist das kein
Problem.

[Bonita Montero]

>> Man schiebt den Codeblock an die gewünschte Position, vertikal, und bei
>> Python eben auch horizontal. Problem gelöst.

> Das ist eine Wiederholung eines Teils meines Textes. Natürlich kann man
> manuell um diese Sprachdesignproblem herumwürgen.

Das ist kein Problem und das ist kein Herumwürgen.

[Rainer Weikusat]

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Rainer Weikusat <rwei...@talktalk.net> writes:
>> Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
>>> Rainer Weikusat <rwei...@talktalk.net> writes:
>>>>>> Dafür existiert ein anderes Problem: Pythoncode ist
>>>>>> positionsabhängig.

[...]

>>> Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
>>> das Reformat wird der Code schnell unlesbar.
>>
>> In C muß man vor allem nie «neu formatieren», denn es gibt Werkzeuge, die
>> das automatisch erledigen. Das ist mit Python grundsätzlich nicht
>> möglich. Das ist aber mehr ein Nebenaspekt (obwohl es natürlich beim
>> Arbeiten mit existierenden Code vollkommen vermeidbare Mehrarbeit
>> verursacht).
>
> Das gibt es auch in Python. Es ist ja wirklich nur die richtige
> Einrückung, und das macht mein Emacs mit C-c > bzw. C-c < . Eventuell
> mit M-q für den passenden Zeilenumbruch. Über den dazu nötigen
> Zeitaufwand zu reden ist ein wenig müßig, zumal man ja sofort *sieht*,
> ob der Codeblock korrekt eingerückt ist.

Sicher kann das beim schreiben heuristisch einrücken. Ich hatte aber von
etwas anderem geschrieben, nämlich einen existierenden Codeblock, der an
eine andere Textstelle verschoben (oder kopiert) wurde, automatisch so
umzuformatieren, daß er optisch an seine neue Position paßt.

Ist aber wirklich ein relativ uninteressanter Nebenaspekt.

>> Das Problem ist, daß der Inhalt eines zusammenhängende Quellcodeblocks
>> semantisch von allen äußeren Quellcodeblöcken abhängig ist. Damit ist er
>> grundsätzlich kein «strukturiertes» Programmkonstrukt mehr.
>
> Der Inhalt eines "Blocks" ist in Python auch unabhängig vom Rest. Nur
> die Einbindung in die Umgebung hängt von der Einrückung ab.

Die Einrück ist semantisch relevanter Bestandteil des Quelltexts und
hängt in der beschriebenen Art und Weise von allen übergeordneten
Blöcken ab. Kann man als rekursive Funktion definieren: Sei n die
Blocktiefe und f(n) eine Funktion, deren Wert die minimal notwendige
Einrückung eines Blocks an Tiefe n ist, dann gilt

f(0) = 0
f(n) = 1 + f(n - 1)

[Rainer Weikusat]

Stefan Reuther <stefa...@arcor.de> writes:
> Am 30.04.2021 um 16:50 schrieb Ole Streicher:

[...]

> Aber am Ende würde es nicht mehrere Sprachen geben, wenn es nicht
> mehrere Geschmäcker gäbe. Objektorientierung macht in Python irgendwie
> mehr Spaß als in Perl.

Ich betreibe OO-Programmierung in Perl seit ungefähr 25 Jahren und finde
das immer noch eine sehr angenehme Umgebung zum Lösen von Problemen, an
der ich auch immer noch etwas neues, nützliches entdecke[*]. Und damit
meine ich Perl und nicht «die Sprache, die von CPAN-Autoren zufällig
benutzt wird» (obwohl sie sie größtenteils nicht mögen).

[*] Neuestes Beispiel: Dinge wie "epoll event handler" (oder "time event
handler") kann man als Instanzen von Klassen reprästentieren, deren
Destruktor den entsprechenden Abbau implementiert. Finde ich echt
praktisch. Solange mich ein Ereignis interessiert, habe ich das
handler-Objekt auf. Wenn es mich nicht mehr interessiert, kehre ich es
vom Tisch und es räumt sich selber auf.

[Оlе Ѕtrеісhеr]

... der, wenn es denn wirklich relevant wäre, schon in den üblichen
Codeeditoren implementiert wäre. Es ist ja nicht so, dass das (abgesehem
von Spezialfällen, wie dem Ende eines Blocks) nicht weitgehend
automatisierbar wäre.

>>> Das Problem ist, daß der Inhalt eines zusammenhängende Quellcodeblocks
>>> semantisch von allen äußeren Quellcodeblöcken abhängig ist. Damit ist er
>>> grundsätzlich kein «strukturiertes» Programmkonstrukt mehr.
>>
>> Der Inhalt eines "Blocks" ist in Python auch unabhängig vom Rest. Nur
>> die Einbindung in die Umgebung hängt von der Einrückung ab.
>
> Die Einrück ist semantisch relevanter Bestandteil des Quelltexts und
> hängt in der beschriebenen Art und Weise von allen übergeordneten
> Blöcken ab. Kann man als rekursive Funktion definieren: Sei n die
> Blocktiefe und f(n) eine Funktion, deren Wert die minimal notwendige
> Einrückung eines Blocks an Tiefe n ist, dann gilt
>
> f(0) = 0
> f(n) = 1 + f(n - 1)

Man kann Dinge natürlich auch versuchen, theoretisch zu
verschwurbeln. Ich würde die gemeinsame Einrückung eines Codeblocks
nicht als Bestandteil des Blockes selber ansehen.

Ich wüsste nur nicht, warum das von Belang ist.

Ole