Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #237278 > unrolled thread

Neue Späße mit Lua

Back to article view | Back to de.sci.electronics

Contents

  Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-08 09:42 +0100
    Re: Neue Späße mit Lua "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2017-12-08 09:39 +0000
      Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-08 10:40 +0100
        Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-08 10:44 +0100
        Re: Neue Späße mit Lua "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2017-12-08 09:55 +0000
          Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-08 11:05 +0100
            Re: Neue Späße mit Lua "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2017-12-08 11:22 +0000
              Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-08 13:20 +0100
                Re: Neue Späße mit Lua "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2017-12-08 12:42 +0000
                  Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-08 13:49 +0100
                    Re: Neue Späße mit Lua "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2017-12-08 13:16 +0000
                      Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-08 18:14 +0100
                        Re: Neue Späße mit Lua "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2017-12-11 08:55 +0000
                          Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-11 11:38 +0100
                            Re: Neue Späße mit Lua Arno Welzel <usenet@arnowelzel.de> - 2017-12-18 09:24 +0100
                              Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-18 09:48 +0100
                                Re: Neue Späße mit Lua Hartmut Kraus <hartmut.melina@web.de> - 2017-12-18 17:13 +0100
                                Re: Neue Späße mit Lua Arno Welzel <usenet@arnowelzel.de> - 2018-01-01 14:52 +0100
                                  Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-01-01 14:59 +0100
                                    Re: Neue Späße mit Lua Arno Welzel <usenet@arnowelzel.de> - 2018-01-01 17:21 +0100
                                      Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-01-01 17:32 +0100
                                        Re: Neue Späße mit Lua Hartmut Kraus <hartmut.melina@web.de> - 2018-01-01 20:47 +0100
                                      Re: Neue Späße mit Lua Hartmut Kraus <hartmut.melina@web.de> - 2018-01-01 20:45 +0100
                      Re: Neue Späße mit Lua Reinhardt Behm <rbehm@hushmail.com> - 2017-12-18 11:22 +0800
                        Re: Neue Späße mit Lua Rolf Bombach <rolfnospambombach@invalid.invalid> - 2017-12-18 21:39 +0100
                          Re: Neue Späße mit Lua Andreas Karrer <ak-7a@gmx.ch> - 2017-12-18 21:20 +0000
                            Re: Neue Späße mit Lua Rolf Bombach <rolfnospambombach@invalid.invalid> - 2018-01-05 19:24 +0100
                              Re: Neue Späße mit Lua Andreas Karrer <ak-7a@gmx.ch> - 2018-01-05 20:13 +0000
                    Re: Neue Späße mit Lua Johannes Bauer <dfnsonfsduifb@gmx.de> - 2017-12-08 21:39 +0100
                      Re: Neue Späße mit Lua Axel Berger <Spam@Berger-Odenthal.De> - 2017-12-08 21:53 +0100
                        Re: Neue Späße mit Lua Johannes Bauer <dfnsonfsduifb@gmx.de> - 2017-12-08 22:23 +0100
                          Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-09 11:02 +0100
                            Re: Neue Späße mit Lua Johannes Bauer <dfnsonfsduifb@gmx.de> - 2017-12-09 11:09 +0100
                              Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-09 11:15 +0100
                              Re: Neue Späße mit Lua Hartmut Kraus <hartmut.melina@web.de> - 2017-12-10 16:35 +0100
                    Re: Neue Späße mit Lua Hartmut Kraus <hartmut.melina@web.de> - 2017-12-10 19:05 +0100
          Re: Neue Späße mit Lua Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-12-09 12:12 +0100

Page 1 of 2  [1] 2  Next page →

#237278 — Neue Späße mit Lua

Vielleicht kann ja einer hier aus dem Stegreif helfen.

Manche Lua Methoden liefern mehrere Rückgabewerte, das mag manchmal ganz 
praktisch sein, ist aber sehr störend, wenn der Methodenaufruf Parameter 
eines anderen Methodenaufrufs ist. Kann man elegant die weiteren 
Rückgabewerte ignorieren?

Ja, über eine Zwischenvariable kann ich das auch...

[toc] | [next] | [standalone]

#237281

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>Vielleicht kann ja einer hier aus dem Stegreif helfen.

>Manche Lua Methoden liefern mehrere Rückgabewerte, das mag manchmal ganz 
>praktisch sein, ist aber sehr störend, wenn der Methodenaufruf Parameter 
>eines anderen Methodenaufrufs ist. Kann man elegant die weiteren 
>Rückgabewerte ignorieren?

>Ja, über eine Zwischenvariable kann ich das auch...

Das kommt auf die aufrufende Methode an. Wenn diese nur einen Wert erwartet, werden die
restlichen ignoriert. Gerade ausprobiert:

function f(x) x*x,x*x*x end
function z(x) return x end
print(f(3))
9 27
print(z(f(3)))
9

Nachzulesen z.B. unter https://www.lua.org/pil/5.1.html

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#237283

Am 08.12.2017 um 10:39 schrieb Peter Heitzer:
> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>> Vielleicht kann ja einer hier aus dem Stegreif helfen.
>
>> Manche Lua Methoden liefern mehrere Rückgabewerte, das mag manchmal ganz
>> praktisch sein, ist aber sehr störend, wenn der Methodenaufruf Parameter
>> eines anderen Methodenaufrufs ist. Kann man elegant die weiteren
>> Rückgabewerte ignorieren?
>
>> Ja, über eine Zwischenvariable kann ich das auch...
>
> Das kommt auf die aufrufende Methode an. Wenn diese nur einen Wert erwartet, werden die
> restlichen ignoriert. Gerade ausprobiert:
>

Ja - blöd nur, wenn sie weitere Parameter erwartet...

[toc] | [prev] | [next] | [standalone]

#237284

Am 08.12.2017 um 10:40 schrieb Eric Bruecklmeier:
> Am 08.12.2017 um 10:39 schrieb Peter Heitzer:
>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>> Vielleicht kann ja einer hier aus dem Stegreif helfen.
>>
>>> Manche Lua Methoden liefern mehrere Rückgabewerte, das mag manchmal ganz
>>> praktisch sein, ist aber sehr störend, wenn der Methodenaufruf Parameter
>>> eines anderen Methodenaufrufs ist. Kann man elegant die weiteren
>>> Rückgabewerte ignorieren?
>>
>>> Ja, über eine Zwischenvariable kann ich das auch...
>>
>> Das kommt auf die aufrufende Methode an. Wenn diese nur einen Wert
>> erwartet, werden die
>> restlichen ignoriert. Gerade ausprobiert:
>>
>
> Ja - blöd nur, wenn sie weitere Parameter erwartet...
>

Ah, OK es müsste mit

bar({foo(42)}[1],42) gehen?

Hab hier am Platz grad keinen Lua Interpreter, aber so sollte es 
eigentlich machbar sein. Man fragt sich, was die geraucht haben...

[toc] | [prev] | [next] | [standalone]

#237285

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>Am 08.12.2017 um 10:39 schrieb Peter Heitzer:
>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>> Vielleicht kann ja einer hier aus dem Stegreif helfen.
>>
>>> Manche Lua Methoden liefern mehrere Rückgabewerte, das mag manchmal ganz
>>> praktisch sein, ist aber sehr störend, wenn der Methodenaufruf Parameter
>>> eines anderen Methodenaufrufs ist. Kann man elegant die weiteren
>>> Rückgabewerte ignorieren?
>>
>>> Ja, über eine Zwischenvariable kann ich das auch...
>>
>> Das kommt auf die aufrufende Methode an. Wenn diese nur einen Wert erwartet, werden die
>> restlichen ignoriert. Gerade ausprobiert:
>>

>Ja - blöd nur, wenn sie weitere Parameter erwartet...
Wie soll sie denn wissen, welche Parameter sie ignorieren soll? Die sinnvollste Methode
scheint mir, dafür eine einparametrische Hilfsfunktion (bei meinem Beispiel z) zu definieren
und zu verwenden. Wie löst du das Problem in ruby?

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#237287

Am 08.12.2017 um 10:55 schrieb Peter Heitzer:
> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>> Am 08.12.2017 um 10:39 schrieb Peter Heitzer:
>>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>>> Vielleicht kann ja einer hier aus dem Stegreif helfen.
>>>
>>>> Manche Lua Methoden liefern mehrere Rückgabewerte, das mag manchmal ganz
>>>> praktisch sein, ist aber sehr störend, wenn der Methodenaufruf Parameter
>>>> eines anderen Methodenaufrufs ist. Kann man elegant die weiteren
>>>> Rückgabewerte ignorieren?
>>>
>>>> Ja, über eine Zwischenvariable kann ich das auch...
>>>
>>> Das kommt auf die aufrufende Methode an. Wenn diese nur einen Wert erwartet, werden die
>>> restlichen ignoriert. Gerade ausprobiert:
>>>
>
>> Ja - blöd nur, wenn sie weitere Parameter erwartet...
> Wie soll sie denn wissen, welche Parameter sie ignorieren soll? Die sinnvollste Methode
> scheint mir, dafür eine einparametrische Hilfsfunktion (bei meinem Beispiel z) zu definieren
> und zu verwenden. Wie löst du das Problem in ruby?

Durch Rückgabe eines Objektes.

[toc] | [prev] | [next] | [standalone]

#237293

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>Am 08.12.2017 um 10:55 schrieb Peter Heitzer:
>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>> Am 08.12.2017 um 10:39 schrieb Peter Heitzer:
>>>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>>>> Vielleicht kann ja einer hier aus dem Stegreif helfen.
>>>>
>>>>> Manche Lua Methoden liefern mehrere Rückgabewerte, das mag manchmal ganz
>>>>> praktisch sein, ist aber sehr störend, wenn der Methodenaufruf Parameter
>>>>> eines anderen Methodenaufrufs ist. Kann man elegant die weiteren
>>>>> Rückgabewerte ignorieren?
>>>>
>>>>> Ja, über eine Zwischenvariable kann ich das auch...
>>>>
>>>> Das kommt auf die aufrufende Methode an. Wenn diese nur einen Wert erwartet, werden die
>>>> restlichen ignoriert. Gerade ausprobiert:
>>>>
>>
>>> Ja - blöd nur, wenn sie weitere Parameter erwartet...
>> Wie soll sie denn wissen, welche Parameter sie ignorieren soll? Die sinnvollste Methode
>> scheint mir, dafür eine einparametrische Hilfsfunktion (bei meinem Beispiel z) zu definieren
>> und zu verwenden. Wie löst du das Problem in ruby?

>Durch Rückgabe eines Objektes.

Also IMO gar nicht, sondern vermeidest diesen Fall nur geflissentlich :-;
Eine Liste als Rückgabewert halte ich für keine unvernünftige Idee.
Schreibst du unter ruby dann z.B. bla(fasl(1,2).blub,42), wenn du an bla() nur den Member blub
des Rückgabeobjektes von fasl() übergeben willst?

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#237300

Am 08.12.2017 um 12:22 schrieb Peter Heitzer:
> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>> Am 08.12.2017 um 10:55 schrieb Peter Heitzer:
>>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>>> Am 08.12.2017 um 10:39 schrieb Peter Heitzer:
>>>>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>>>>> Vielleicht kann ja einer hier aus dem Stegreif helfen.
>>>>>
>>>>>> Manche Lua Methoden liefern mehrere Rückgabewerte, das mag manchmal ganz
>>>>>> praktisch sein, ist aber sehr störend, wenn der Methodenaufruf Parameter
>>>>>> eines anderen Methodenaufrufs ist. Kann man elegant die weiteren
>>>>>> Rückgabewerte ignorieren?
>>>>>
>>>>>> Ja, über eine Zwischenvariable kann ich das auch...
>>>>>
>>>>> Das kommt auf die aufrufende Methode an. Wenn diese nur einen Wert erwartet, werden die
>>>>> restlichen ignoriert. Gerade ausprobiert:
>>>>>
>>>
>>>> Ja - blöd nur, wenn sie weitere Parameter erwartet...
>>> Wie soll sie denn wissen, welche Parameter sie ignorieren soll? Die sinnvollste Methode
>>> scheint mir, dafür eine einparametrische Hilfsfunktion (bei meinem Beispiel z) zu definieren
>>> und zu verwenden. Wie löst du das Problem in ruby?
>
>> Durch Rückgabe eines Objektes.
>
> Also IMO gar nicht, sondern vermeidest diesen Fall nur geflissentlich :-;
> Eine Liste als Rückgabewert halte ich für keine unvernünftige Idee.

Ich halte das für großen Stuß.

> Schreibst du unter ruby dann z.B. bla(fasl(1,2).blub,42), wenn du an bla() nur den Member blub
> des Rückgabeobjektes von fasl() übergeben willst?
>

Ja klar, aber eher

foo.bla(fasel.humpf(42).blub,42)

[toc] | [prev] | [next] | [standalone]

#237305

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>Am 08.12.2017 um 12:22 schrieb Peter Heitzer:
>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>> Am 08.12.2017 um 10:55 schrieb Peter Heitzer:
>>>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>>>> Am 08.12.2017 um 10:39 schrieb Peter Heitzer:
>>>>>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>>>>>> Vielleicht kann ja einer hier aus dem Stegreif helfen.
>>>>>>
>>>>>>> Manche Lua Methoden liefern mehrere Rückgabewerte, das mag manchmal ganz
>>>>>>> praktisch sein, ist aber sehr störend, wenn der Methodenaufruf Parameter
>>>>>>> eines anderen Methodenaufrufs ist. Kann man elegant die weiteren
>>>>>>> Rückgabewerte ignorieren?
>>>>>>
>>>>>>> Ja, über eine Zwischenvariable kann ich das auch...
>>>>>>
>>>>>> Das kommt auf die aufrufende Methode an. Wenn diese nur einen Wert erwartet, werden die
>>>>>> restlichen ignoriert. Gerade ausprobiert:
>>>>>>
>>>>
>>>>> Ja - blöd nur, wenn sie weitere Parameter erwartet...
>>>> Wie soll sie denn wissen, welche Parameter sie ignorieren soll? Die sinnvollste Methode
>>>> scheint mir, dafür eine einparametrische Hilfsfunktion (bei meinem Beispiel z) zu definieren
>>>> und zu verwenden. Wie löst du das Problem in ruby?
>>
>>> Durch Rückgabe eines Objektes.
>>
>> Also IMO gar nicht, sondern vermeidest diesen Fall nur geflissentlich :-;
>> Eine Liste als Rückgabewert halte ich für keine unvernünftige Idee.

>Ich halte das für großen Stuß.
Die Geschmäcker sind eben verschieden. 

>> Schreibst du unter ruby dann z.B. bla(fasl(1,2).blub,42), wenn du an bla() nur den Member blub
>> des Rückgabeobjektes von fasl() übergeben willst?
>>

>Ja klar, aber eher

>foo.bla(fasel.humpf(42).blub,42)

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#237306

Am 08.12.2017 um 13:42 schrieb Peter Heitzer:

> Die Geschmäcker sind eben verschieden.


Sicher, es scheint ja auch klar, warum Lua das so löst. Lua hatte ein 
völlig anderes Designziel als z.B. ruby.

Trotzdem liebe ich den konsequenten OO Ansatz von ruby. Sowas läßt sich 
an Eleganz einfach nicht übertreffen:

3.times {|x| print x}


;-)

[toc] | [prev] | [next] | [standalone]

#237313

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>Am 08.12.2017 um 13:42 schrieb Peter Heitzer:

>> Die Geschmäcker sind eben verschieden.


>Sicher, es scheint ja auch klar, warum Lua das so löst. Lua hatte ein 
>völlig anderes Designziel als z.B. ruby.

>Trotzdem liebe ich den konsequenten OO Ansatz von ruby. Sowas läßt sich 
>an Eleganz einfach nicht übertreffen:

>3.times {|x| print x}
Für geeignete Werte von Eleganz. Wer nicht in ruby programmiert, sieht es eher als Obfuscation :-)





>;-)




-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#237350

Am 08.12.2017 um 14:16 schrieb Peter Heitzer:
> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>> Am 08.12.2017 um 13:42 schrieb Peter Heitzer:
> 
>>> Die Geschmäcker sind eben verschieden.
> 
> 
>> Sicher, es scheint ja auch klar, warum Lua das so löst. Lua hatte ein
>> völlig anderes Designziel als z.B. ruby.
> 
>> Trotzdem liebe ich den konsequenten OO Ansatz von ruby. Sowas läßt sich
>> an Eleganz einfach nicht übertreffen:
> 
>> 3.times {|x| print x}
> Für geeignete Werte von Eleganz. Wer nicht in ruby programmiert, sieht es eher als Obfuscation :-)

was ist an Methoden für ein INT Objekt unklar? Der Ansatz, daß jedes 
Objekt seine eigenen Methoden mitbringt ist doch genial.

Schöner als

print 42.4711.floor

gehts doch nun wirklich nicht...

[toc] | [prev] | [next] | [standalone]

#237613

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>Am 08.12.2017 um 14:16 schrieb Peter Heitzer:
>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>> Am 08.12.2017 um 13:42 schrieb Peter Heitzer:
>> 
>>>> Die Geschmäcker sind eben verschieden.
>> 
>> 
>>> Sicher, es scheint ja auch klar, warum Lua das so löst. Lua hatte ein
>>> völlig anderes Designziel als z.B. ruby.
>> 
>>> Trotzdem liebe ich den konsequenten OO Ansatz von ruby. Sowas läßt sich
>>> an Eleganz einfach nicht übertreffen:
>> 
>>> 3.times {|x| print x}
>> Für geeignete Werte von Eleganz. Wer nicht in ruby programmiert, sieht es eher als Obfuscation :-)

>was ist an Methoden für ein INT Objekt unklar? Der Ansatz, daß jedes 
>Objekt seine eigenen Methoden mitbringt ist doch genial.
Die INT-Methode ist schon klar; das Konstrukt in geschweiften Klammern
erschliesst sich einem nicht sofort. 

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#237623

Am 11.12.2017 um 09:55 schrieb Peter Heitzer:
> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>> Am 08.12.2017 um 14:16 schrieb Peter Heitzer:
>>> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>>>> Am 08.12.2017 um 13:42 schrieb Peter Heitzer:
>>>
>>>>> Die Geschmäcker sind eben verschieden.
>>>
>>>
>>>> Sicher, es scheint ja auch klar, warum Lua das so löst. Lua hatte ein
>>>> völlig anderes Designziel als z.B. ruby.
>>>
>>>> Trotzdem liebe ich den konsequenten OO Ansatz von ruby. Sowas läßt sich
>>>> an Eleganz einfach nicht übertreffen:
>>>
>>>> 3.times {|x| print x}
>>> Für geeignete Werte von Eleganz. Wer nicht in ruby programmiert, sieht es eher als Obfuscation :-)
>
>> was ist an Methoden für ein INT Objekt unklar? Der Ansatz, daß jedes
>> Objekt seine eigenen Methoden mitbringt ist doch genial.
> Die INT-Methode ist schon klar; das Konstrukt in geschweiften Klammern
> erschliesst sich einem nicht sofort.
>

Ja, da kann ich zustimmen. Aber wenn man einmal das Prinzip Codeblock 
erkannt hat wirds auch wieder relativ klar.

[toc] | [prev] | [next] | [standalone]

#237996

Eric Bruecklmeier:

> Am 11.12.2017 um 09:55 schrieb Peter Heitzer:
[...]
>>>>> 3.times {|x| print x}
[...]
> Ja, da kann ich zustimmen. Aber wenn man einmal das Prinzip Codeblock 
> erkannt hat wirds auch wieder relativ klar.

Nein, auch dann nicht. Was bedeutet "|x|" darin? Ohne einen Blick in die
Dokumentation von Ruby ist das absolut unklar.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#237997

Am 18.12.2017 um 09:24 schrieb Arno Welzel:
> Eric Bruecklmeier:
>
>> Am 11.12.2017 um 09:55 schrieb Peter Heitzer:
> [...]
>>>>>> 3.times {|x| print x}
> [...]
>> Ja, da kann ich zustimmen. Aber wenn man einmal das Prinzip Codeblock
>> erkannt hat wirds auch wieder relativ klar.
>
> Nein, auch dann nicht. Was bedeutet "|x|" darin? Ohne einen Blick in die
> Dokumentation von Ruby ist das absolut unklar.

Ich habe den Eindruck, daß Du das POLS nicht verstanden hast oder auch 
gar nicht verstehen willst. Es geht nicht darum, daß ein Fußgänger 
plötzlich und ohne Manual programmieren kann, sondern es geht darum 
Überraschungen (wie das Zählen von 1 an) zu vermeiden...

[toc] | [prev] | [next] | [standalone]

#238031

Am 18.12.2017 um 09:48 schrieb Eric Bruecklmeier:
> Am 18.12.2017 um 09:24 schrieb Arno Welzel:
>> Eric Bruecklmeier:
>>
>>> Am 11.12.2017 um 09:55 schrieb Peter Heitzer:
>> [...]
>>>>>>> 3.times {|x| print x}
>> [...]
>>> Ja, da kann ich zustimmen. Aber wenn man einmal das Prinzip Codeblock
>>> erkannt hat wirds auch wieder relativ klar.
>>
>> Nein, auch dann nicht. Was bedeutet "|x|" darin? Ohne einen Blick in die
>> Dokumentation von Ruby ist das absolut unklar.
>
> Ich habe den Eindruck, daß Du das POLS nicht verstanden hast oder auch
> gar nicht verstehen willst. Es geht nicht darum, daß ein Fußgänger
> plötzlich und ohne Manual programmieren kann, sondern es geht darum
> Überraschungen (wie das Zählen von 1 an) zu vermeiden...

Dann darfst du dich mit keiner "neuen" (dir bislang "relativ 
unbekannten") Programmiersprache beschäftigen. In welchem Elfenbeinturm 
leben und lehren Sie eigentlich, Herr Professor?

-- 
http://www.hkraus.eu/

[toc] | [prev] | [next] | [standalone]

#238869

Eric Bruecklmeier:

> Am 18.12.2017 um 09:24 schrieb Arno Welzel:
>> Eric Bruecklmeier:
>>
>>> Am 11.12.2017 um 09:55 schrieb Peter Heitzer:
>> [...]
>>>>>>> 3.times {|x| print x}
>> [...]
>>> Ja, da kann ich zustimmen. Aber wenn man einmal das Prinzip Codeblock
>>> erkannt hat wirds auch wieder relativ klar.
>>
>> Nein, auch dann nicht. Was bedeutet "|x|" darin? Ohne einen Blick in die
>> Dokumentation von Ruby ist das absolut unklar.
> 
> Ich habe den Eindruck, daß Du das POLS nicht verstanden hast oder auch 
> gar nicht verstehen willst. Es geht nicht darum, daß ein Fußgänger 
> plötzlich und ohne Manual programmieren kann, sondern es geht darum 
> Überraschungen (wie das Zählen von 1 an) zu vermeiden...

Auch wenn ich mich wiederhole: derlei "Überraschungen" hängen von der
Erfahrung ab, die jemand im Umgang mit einem Thema hat. Je mehr man
kennt, desto weniger ist man überrascht, wenn ein vermeintlich bekanntes
Prinzip im Detail dann doch anders funktioniert.

Wenn man von POLS im Zusammenhang mit Software spricht, meint man damit
auch eher, wie man eine Software für Endanwender so gestaltet, dass
diese bekannte Erfahrungen anwenden können und nicht durch unerwartete
Vorgehensweisen überrascht werden.

Ob nun C++ auch für jemanden mit wenig Überraschungen verständlich ist,
der bisehr nur Python oder Java kennt, ist mit POLS eher nicht gemeint.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#238870

Am 01.01.2018 um 14:52 schrieb Arno Welzel:
> Eric Bruecklmeier:
> 
>> Am 18.12.2017 um 09:24 schrieb Arno Welzel:
>>> Eric Bruecklmeier:
>>>
>>>> Am 11.12.2017 um 09:55 schrieb Peter Heitzer:
>>> [...]
>>>>>>>> 3.times {|x| print x}
>>> [...]
>>>> Ja, da kann ich zustimmen. Aber wenn man einmal das Prinzip Codeblock
>>>> erkannt hat wirds auch wieder relativ klar.
>>>
>>> Nein, auch dann nicht. Was bedeutet "|x|" darin? Ohne einen Blick in die
>>> Dokumentation von Ruby ist das absolut unklar.
>>
>> Ich habe den Eindruck, daß Du das POLS nicht verstanden hast oder auch
>> gar nicht verstehen willst. Es geht nicht darum, daß ein Fußgänger
>> plötzlich und ohne Manual programmieren kann, sondern es geht darum
>> Überraschungen (wie das Zählen von 1 an) zu vermeiden...
> 
> Auch wenn ich mich wiederhole: derlei "Überraschungen" hängen von der
> Erfahrung ab, die jemand im Umgang mit einem Thema hat.

Auch wenn ich mich wiederhole: Diese Ansicht kann ich nicht teilen.

> Je mehr man
> kennt, desto weniger ist man überrascht, wenn ein vermeintlich bekanntes
> Prinzip im Detail dann doch anders funktioniert.
> 
> Wenn man von POLS im Zusammenhang mit Software spricht,

Davon sprach ich aber ganz offensichtlich nicht.

> meint man damit
> auch eher, wie man eine Software für Endanwender so gestaltet, dass
> diese bekannte Erfahrungen anwenden können und nicht durch unerwartete
> Vorgehensweisen überrascht werden.
> 
> Ob nun C++ auch für jemanden mit wenig Überraschungen verständlich ist,
> der bisehr nur Python oder Java kennt, ist mit POLS eher nicht gemeint.

Sagt wer?

[toc] | [prev] | [next] | [standalone]

#238884

Eric Bruecklmeier:

> Am 01.01.2018 um 14:52 schrieb Arno Welzel:
>> Eric Bruecklmeier:
[...]
>>> Ich habe den Eindruck, daß Du das POLS nicht verstanden hast oder auch
>>> gar nicht verstehen willst. Es geht nicht darum, daß ein Fußgänger
>>> plötzlich und ohne Manual programmieren kann, sondern es geht darum
>>> Überraschungen (wie das Zählen von 1 an) zu vermeiden...
>>
>> Auch wenn ich mich wiederhole: derlei "Überraschungen" hängen von der
>> Erfahrung ab, die jemand im Umgang mit einem Thema hat.
> 
> Auch wenn ich mich wiederhole: Diese Ansicht kann ich nicht teilen.

Dann sei es so. Wer Software entwickeln will, muss lernen, dass nicht
jede Sprache gleich aufgebaut ist und nach den gleichen Prinzipien arbeitet.

>> Je mehr man
>> kennt, desto weniger ist man überrascht, wenn ein vermeintlich bekanntes
>> Prinzip im Detail dann doch anders funktioniert.
>>
>> Wenn man von POLS im Zusammenhang mit Software spricht,
> 
> Davon sprach ich aber ganz offensichtlich nicht.

Und worüber reden wir hier die ganze Zeit, wenn nicht über Software?

[...]
>> Ob nun C++ auch für jemanden mit wenig Überraschungen verständlich ist,
>> der bisehr nur Python oder Java kennt, ist mit POLS eher nicht gemeint.
> 
> Sagt wer?

Ich.

Ansonsten siehe auch: <http://www.faqs.org/docs/artu/ch11s01.html>


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.sci.electronics

csiph-web