---

Hej,

Jeg har en variabel, jeg gerne vil kaste igennem en sub igen og igen,
indtil variablen ikke ændrer sig mere.

Det kan man jo snildt gøre på en række måder. I andre sprog (fx C++ og
PHP) kan jeg fx køre:
while ($i != $i = foo($i));

Dette synes jeg tillige er mere overskueligt end en egentligt løkke
med midlertidige variable for værdien af sidste kørsel, etc.


Det nærmeste, jeg dog kommer på dette i perl, er:
while ($i ne foo($i) && ($i = foo($i))) { }

Her bliver jeg dog nødt til at afvikle foo() to gange. Kan det gøres
mere simpelt? Hvad har jeg overset?

--
- Peter Brodersen

Ugens sprogtip: parentes (og ikke parantes)

---

On Sun, 03 Aug 2003 21:06:33 +0200, Peter Brodersen <usenet@ter.dk> wrote:

> Det nærmeste, jeg dog kommer på dette i perl, er:
> while ($i ne foo($i) && ($i = foo($i))) { }
>
> Her bliver jeg dog nødt til at afvikle foo() to gange. Kan det gøres
> mere simpelt? Hvad har jeg overset?

Du har overset at beregningen kan gemmes midlertidigt i en anden
variabel og sammelignes herfra. Desuden finder jeg semantikken for
statement-udførsel i expressions forvirrende.

--
Jesper

---

On Mon, 4 Aug 2003 08:48:45 +0000 (UTC), jlouis@pc-063.diku.dk (Jesper
Louis Andersen) wrote:

>Du har overset at beregningen kan gemmes midlertidigt i en anden
>variabel og sammelignes herfra.

Nej, jeg skrev, at jeg gerne ville undgå det.

At et udtryk måske ikke er 100% letlæseligt første gang, rører mig
ikke så meget, hvis man blot betragter det som et idiom. Men jeg vil
helst ikke have midlertidige værdier ind over.

>Desuden finder jeg semantikken for
>statement-udførsel i expressions forvirrende.

Det er så en anden sag :) Som sagt, jeg vil bare gerne have banket det
ind i en oneliner, uden at skulle have adskilte udtryk eller andre
variabelnavne undervejs.

--
- Peter Brodersen

Ugens sprogtip: parentes (og ikke parantes)

---

In article <bgjmep$60v$1@dknews.tiscali.dk>,
Peter Brodersen <usenet@ter.dk> wrote:

> Hej,
>
> Jeg har en variabel, jeg gerne vil kaste igennem en sub igen og igen,
> indtil variablen ikke ændrer sig mere.
>
> Det kan man jo snildt gøre på en række måder. I andre sprog (fx C++ og
> PHP) kan jeg fx køre:
> while ($i != $i = foo($i));

Hmm. Jeg ved ikke med PHP, men i C (og dermed formentlig også C++, selv
om man jo aldrig kan vide, med operator overloading etc) er:

while(i!=(i=foo(i)));

så vidt jeg kan se 100% ækvivalent med

i=foo(i);

(i!=i) er false, og i det hele taget ikke nogen lvalue, så flg
parentetisering (?)
while((i!=i)=foo(i));

duer ikke.

Hvis PHP virkelig gør det du siger, så stinker PHP.

Jeg har svært ved at forestille mig hvordan dette i det hele taget
skulle være nyttigt, med mindre foo har sideeffekter.

Men for sjovs skyld, lad os antage foo(i) returnerer et tilfældigt tal
mellem 1 og i, inklusive (antag i er positivt heltal), eller for den
sags skyld at foo(s) er en tilfældig permutation af tegnene i strengen s
(du brugte jo ne i dit Perl-eksempel.)

Du ønsker så at terminere når foo to gange i træk returnerer samme tal,
eller samme permutation af s. (Hvorfor i himlens navn du ville gøre det,
ved jeg ikke.)

Det kan du ikke gøre uden at huske den forrige værdi. Så enkelt er det.
Hvis PHP gør det bag om ryggen på dig, så er det efter min mening en
alvorlig fejl i PHP.
I C (og Perl for den sags skyld) kunne man gøre:
i=foo(i);
while(i!=foo(i)) i=foo(i);

men altså ikke det du foreslår.

> Dette synes jeg tillige er mere overskueligt end en egentligt løkke
> med midlertidige variable for værdien af sidste kørsel, etc.
>
>
> Det nærmeste, jeg dog kommer på dette i perl, er:
> while ($i ne foo($i) && ($i = foo($i))) { }
>
> Her bliver jeg dog nødt til at afvikle foo() to gange. Kan det gøres
> mere simpelt? Hvad har jeg overset?

Måske at PHP er noget skrammel? Et Dat1 kursus? Et par sider i
Kernighan&Ritchie? Hvad ved jeg?

-Lasse

---

Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:

> Jeg har svært ved at forestille mig hvordan dette i det hele taget
> skulle være nyttigt, med mindre foo har sideeffekter.

Jeg har tit fundet fikspunkter af matematiske funktioner, som ikke har
haft nogle sidevirkninger. Ganske nyttingt, specielt når det kan gøres
i endelig tid.

--
Peter Makholm | If you can't do any damage as root, are you still
peter@makholm.net | really root?
http://hacking.dk | -- Derek Gladding about SELinux

---

In article <87d6f9q5jl.fsf@xyzzy.adsl.dk>,
Peter Makholm <peter@makholm.net> wrote:

> Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:
>
> > Jeg har svært ved at forestille mig hvordan dette i det hele taget
> > skulle være nyttigt, med mindre foo har sideeffekter.
>
> Jeg har tit fundet fikspunkter af matematiske funktioner, som ikke har
> haft nogle sidevirkninger. Ganske nyttingt, specielt når det kan gøres
> i endelig tid.

Nøgleordet her er da vist "endelig". Nu skal jeg gerne indrømme at jeg
droppede ud af datalogien og blev humanist, fordi jeg ikke var god nok
til matematikken, som den så ud på datalogistudiet ved AU i 1987-89.

Men at beregne et fikspunkt på denne måde, er så vidt jeg - med min
mangel på matematisk indsigt, og dermed kun ud fra common sense - kan se
lidt farligt. Mon ikke der skulle findes temmelig mange funktioner, for
hvilke denne metode ikke terminerer? Så kan det være ligegyldigt om man
kan skrive det som en one-liner, efter min mening. Især hvis man derved
benytter sig af en semantisk spidsfindighed i det sprog man skriver
one-lineren i. Hvis man ved at den under de givne omstændigheder vil
terminere er det noget andet; men hvis man ikke ved det, vil jeg
fastholde at den ikke er nyttig.

Men det jeg i øvrigt hæftede mig ved var påstanden om at
> > > while ($i != $i = foo($i));

skulle være forskellig fra "$i = foo($i)", med mindre sprogets semantik
er ret bizar. Jeg gjorde gældende at det næppe er tilfældet (som
påstået) i C++. Jeg vil faktisk gerne vide om det er tilfældet i PHP. Og
jeg vil da selvfølgelig især gerne vide det, hvis jeg mod forventning
skulle tage fejl mht C og C++.


-Lasse

---

Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:

> Men at beregne et fikspunkt på denne måde, er så vidt jeg - med min
> mangel på matematisk indsigt, og dermed kun ud fra common sense - kan se
> lidt farligt. Mon ikke der skulle findes temmelig mange funktioner, for
> hvilke denne metode ikke terminerer?

Lad os skraks stoppe med at bruge ethvert programmeringssprog der er
Turingkomplet. Det er den eneste naturlige følge af din argumentation.

> Men det jeg i øvrigt hæftede mig ved var påstanden om at
>> > > while ($i != $i = foo($i));
>
> skulle være forskellig fra "$i = foo($i)", med mindre sprogets semantik
> er ret bizar.

Hmmmm, egentligt ikke. Med en streng fra højre til venstre-evaluering
er det faktisk indlysende at ovenstående burde være en
fikspunkt-operator.

Hmmm, prøv at betragt følgende to kodestumper:

perl -le '$i++;sub f{$_[0]<10?$_[0]+1:15} while(($i = f(+$i)) != $i){print $i}'
perl -le '$i++;sub f{$_[0]<10?$_[0]+1:15} while($i != ($i = f($i))){print $i}'

Det virker som om evalueringsrækkefølgen ikke er helt fast?

Den er i hvert fald hverken streng højre til venstre eller venstre til
højre. Nu er jeg egentligt nysgerig.

--
Peter Makholm | The four letter word beginning with L?
peter@makholm.net | It's life, love, libc or lisp
http://hacking.dk | -- Depending on you point of view

---

In article <877k5hq0mm.fsf@xyzzy.adsl.dk>,
Peter Makholm <peter@makholm.net> wrote:

> Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:
>
> > Men at beregne et fikspunkt på denne måde, er så vidt jeg - med min
> > mangel på matematisk indsigt, og dermed kun ud fra common sense - kan se
> > lidt farligt. Mon ikke der skulle findes temmelig mange funktioner, for
> > hvilke denne metode ikke terminerer?
>
> Lad os skraks stoppe med at bruge ethvert programmeringssprog der er
> Turingkomplet. Det er den eneste naturlige følge af din argumentation.

Du vrøvler.

Hvis man ikke ved om foo har et fikspunkt, kan man ikke være sikker på
at den terminerer (og ikke en gang hvis den har). Og hvis man afbryder
iterationen, fordi man ikke gider vente længere, kan man ikke vide om
den faktisk havde et fikspunkt. Længere når man ikke uden at analysere
foo algoritmisk.

> > Men det jeg i øvrigt hæftede mig ved var påstanden om at
> >> > > while ($i != $i = foo($i));
> >
> > skulle være forskellig fra "$i = foo($i)", med mindre sprogets semantik
> > er ret bizar.
>
> Hmmmm, egentligt ikke. Med en streng fra højre til venstre-evaluering
> er det faktisk indlysende at ovenstående burde være en
> fikspunkt-operator.

C garanterer ikke en sådan evaluering i alle tilfælde. Næppe heller C++.
PHP ved jeg som sagt intet om. Hvis et sprog kan udføre en operation
uden at værdien af begge operander er kendt, vil jeg ikke tøve med at
kalde det bizart.

perl -le '$i++;sub f{ print"f with $_[0]\n"; $_[0]<10?$_[0]+1:15}
while($i = f(+$i) != $i){print $i}'

er en uendelig løkke, fordi det er semantisk identisk med:
perl -le '$i++;sub f{ print"f with $_[0]\n"; $_[0]<10?$_[0]+1:15}
while($i = (f(+$i) != $i)){print $i}'

pga operator-præcedens. Samme gælder C.

perl -le '$i++;sub f{ print"f with $_[0]\n"; $_[0]<10?$_[0]+1:15}
while($i != $i = f(+$i)){print $i}'

giver naturligvis:

Can't modify numeric ne (!=) in scalar assignment at -e line 1, near "))"
Execution of -e aborted due to compilation errors.

og tilsvarende "foo1.c:10: invalid lvalue in assignment" for ækvivalent
C kode.

> Hmmm, prøv at betragt følgende to kodestumper:
>
> perl -le '$i++;sub f{$_[0]<10?$_[0]+1:15} while(($i = f(+$i)) != $i){print
> $i}'
> perl -le '$i++;sub f{$_[0]<10?$_[0]+1:15} while($i != ($i = f($i))){print
> $i}'
>
> Det virker som om evalueringsrækkefølgen ikke er helt fast?

Parentesen evalueres naturligvis først i begge tilfælde. Ingen af de
ovenstående itererer, fordi $i == $i. De finder ikke 15 som fixpunkt.
Hvad var din pointe? (Eller hvad troede du den var, for der er ingen
pointe i de ovenfor citerede "to kodestumper"?)

Man kunne måske lave et argument der kunne overbevise dig, ved at lade
$i være en tied variabel (som printer en meddelelse ved FETCH), samt
printe en meddelelse ved entry og exit af f.

Men ærligt talt gider jeg ikke. Balker, gider du svinge en passende LART?

-Lasse

---

Thorbjoern Ravn Andersen <nospam0000@unixsnedkeren.dk> writes:
> Du har lige sat fingere præcis på de forskellige krypteringsmetoder
> til identifikation. Hvem stoler man på til at begynde med? I Danmark
> _kunne_ det måske være staten, men hverken Microsoft eller TDC i mine øjne.

Kongehuset! Det ville være helt oplagt at lægge denne funktion hos
dronningen.
--
Lars Balker Rasmussen Consult::Perl

---

Peter Makholm <peter@makholm.net> writes:

> perl -le '$i++;sub f{$_[0]<10?$_[0]+1:15} while(($i = f(+$i)) != $i){print $i}'
> perl -le '$i++;sub f{$_[0]<10?$_[0]+1:15} while($i != ($i = f($i))){print $i}'
>
> Det virker som om evalueringsrækkefølgen ikke er helt fast?
>
> Den er i hvert fald hverken streng højre til venstre eller venstre til
> højre. Nu er jeg egentligt nysgerig.

Ok, Standardeksemplet på perls uforudsigelige evalueringsrækkefølge er
tilsyneladnede:

plugh% perl -le '$x=10; print --$x / $x++'
1.11111111111111
plugh%

Det må være en Heisenbug, for uanset hvordan man tilføjer noget der
'observerer $x' så ser det rigtigt ud:

plugh% perl -le '$x=10; print (($i = --$x) / ($j = $x++))'
1
plugh% perl -le 'sub id{$_[0]}$x=10; print id(--$x) / id($x++)'
1
plugh%

--
Peter Makholm | Ladies and gentlemen, take my advice, pull down your
peter@makholm.net | pants and slide on the ice
http://hacking.dk | -- Sidney Freedman

---

Peter Makholm <peter@makholm.net> writes:

> Det må være en Heisenbug, for uanset hvordan man tilføjer noget der
> 'observerer $x' så ser det rigtigt ud:

Ha, jeg er smartere end perl:

plugh% cat tietest.pl
#!/usr/bin/perl

package MyScalar;
require Tie::Scalar; @ISA = qw(Tie::Scalar);

sub TIESCALAR { my $scalar = 0; return bless \$scalar, "MyScalar" }
sub FETCH { print "Fetched $$_[0]\n"; $$_[0] }
sub STORE { print "Stored $_[1]\n"; $$_[0] = $_[1] }

package main;

tie $x, "MyScalar";
$x = 10;
print "--\$x + 1 giver:\n"; --$x + 1;
print "\$x++ + 1 giver:\n"; $x++ + 1;
print "Reset \$x\n";
$x = 10;
print "Gør det sjove\n";
print --$x / $x++, "\n";
plugh% perl tietest.pl
Stored 10
--$x + 1 giver:
Fetched 10
Stored 9
Fetched 9
$x++ + 1 giver:
Fetched 9
Fetched 9
Stored 10
Reset $x
Stored 10
Gør det sjove
Fetched 10
Stored 9
Fetched 9
Fetched 9
Stored 10
Fetched 10
1.11111111111111
plugh%

Det ser jo helt klart forkert ud. De sidste tre linjer bør hedder
fetch, fetch, store.

Undervejs prøvede jeg også:
plugh% perl -le '$x=10; print ( ($x=$x-1,$x) / ($t=$x,$x=$x+1,$t) )'
1.11111111111111
plugh%

Det er måske egentligt tydeligere at den begynder med at evaluerer
tildelinger fra venstre mod højre og derefter evaluerer resten fra
venstre mod højre.

--
Peter Makholm | Ladies and gentlemen, take my advice, pull down your
peter@makholm.net | pants and slide on the ice
http://hacking.dk | -- Sidney Freedman

---

Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:

> In article <877k5hq0mm.fsf@xyzzy.adsl.dk>,
> Peter Makholm <peter@makholm.net> wrote:
>
>> Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:
>>
>> > Men at beregne et fikspunkt på denne måde, er så vidt jeg - med min
>> > mangel på matematisk indsigt, og dermed kun ud fra common sense - kan se
>> > lidt farligt. Mon ikke der skulle findes temmelig mange funktioner, for
>> > hvilke denne metode ikke terminerer?
>>
>> Lad os skraks stoppe med at bruge ethvert programmeringssprog der er
>> Turingkomplet. Det er den eneste naturlige følge af din argumentation.
>
> Du vrøvler.

Nej. Hvis du ikke vil beregne fikspunkter fordi de i mange tilfælde
kan gå i uendelig løkke så bør du holde dig fra programmering
generelt.

> C garanterer ikke en sådan evaluering i alle tilfælde. Næppe heller C++.

C er notorisk kendt for ikke at definere særlig meget.

> PHP ved jeg som sagt intet om. Hvis et sprog kan udføre en operation
> uden at værdien af begge operander er kendt, vil jeg ikke tøve med at
> kalde det bizart.

De fleste sprog har short-circuit-operatore. ?: er også en doven
operator. og så er der selvfølgelig sprog der generelt har doven
evaluering.

Dine eksempler er uinteressante.

> Can't modify numeric ne (!=) in scalar assignment at -e line 1, near "))"
> Execution of -e aborted due to compilation errors.
>
> og tilsvarende "foo1.c:10: invalid lvalue in assignment" for ækvivalent
> C kode.
>
>> Hmmm, prøv at betragt følgende to kodestumper:
>>
>> perl -le '$i++;sub f{$_[0]<10?$_[0]+1:15} while(($i = f(+$i)) != $i){print
>> $i}'
>> perl -le '$i++;sub f{$_[0]<10?$_[0]+1:15} while($i != ($i = f($i))){print
>> $i}'
>>
>> Det virker som om evalueringsrækkefølgen ikke er helt fast?
>
> Parentesen evalueres naturligvis først i begge tilfælde.

Nej, det er ikke naturligt!

En hvilken som helst fornuftig, formel, deterministisk semantik ville
i et udtryk 'e1 op e2' evaluerer enten e1 eller e2 først, men aldrig
vælge ud fra deludtrykkenes struktur.

> Man kunne måske lave et argument der kunne overbevise dig, ved at lade
> $i være en tied variabel (som printer en meddelelse ved FETCH), samt
> printe en meddelelse ved entry og exit af f.

Prøv at læs tråden. Jeg er langt foran dig.

> Men ærligt talt gider jeg ikke. Balker, gider du svinge en passende LART?

Det må være over dig.

--
Peter Makholm | Perhaps that late-night surfing is not such a
peter@makholm.net | waste of time after all: it is just the web
http://hacking.dk | dreaming
| -- Tim Berners-Lee

---

In article <87ptj6sibb.fsf@xyzzy.adsl.dk>,
Peter Makholm <peter@makholm.net> wrote:

> Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:


> > Men ærligt talt gider jeg ikke. Balker, gider du svinge en passende LART?
>
> Det må være over dig.

Vi får vel se.

-Lasse

---

Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:
> Peter Makholm <peter@makholm.net> wrote:
>> Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:
>> > Men ærligt talt gider jeg ikke. Balker, gider du svinge en passende LART?
>>
>> Det må være over dig.
>
> Vi får vel se.

Jeg kan ikke se hvorfor jeg skal blandes ind idet, udover for at
påpege at I begge to går efter benene fremfor bolden, og i øvrigt
begge to vrøvler (og/eller taler forbi hinanden i ekvilibristisk stil).

Og Peter ved bedre end at antage at Perl 5 er teoretisk funderet
--
Lars Balker Rasmussen Consult::Perl

---

In article <0fhe4io8wy.fsf@laphroaig.balker.org>,
Lars Balker Rasmussen <lars@balker.org> wrote:

> Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:
> > Peter Makholm <peter@makholm.net> wrote:
> >> Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:
> >> > Men ærligt talt gider jeg ikke. Balker, gider du svinge en passende LART?
> >>
> >> Det må være over dig.
> >
> > Vi får vel se.
>
> Jeg kan ikke se hvorfor jeg skal blandes ind idet, udover for at

Som sagt, jeg gider ikke. Jeg tænkte du måske gad. Du gider heller ikke.
End of story. Jeg står ved det jeg har skrevet. Hvis der er nogen andre
der synes de gider prøve at udrede noget her, så værsgo.

Jeg vil stadig gerne vide det hvis jeg tager fejl mht PHP. Uden at blive
beskudt med fabelagtige tåbeligheder som:
....>
....> Lad os skraks stoppe med at bruge ethvert programmeringssprog der er
....> Turingkomplet. Det er den eneste naturlige følge af din
argumentation.


-Lasse

---

Lasse Hillerøe Petersen wrote:

> Jeg vil stadig gerne vide det hvis jeg tager fejl mht PHP. Uden at
> blive beskudt med fabelagtige tåbeligheder som:

Det er lidt svært at sige om du tager fejl, når du udtaler "Hvis PHP
virkelig gør det du siger, så stinker PHP." Men PHP kan det, som Peters
eksempel viser.

--
Take Care
Kim Emax - Freelance programmør - opgaver modtages
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

In article <cze%a.50780$Kb2.2296696@news010.worldonline.dk>,
"Kim Emax" <newsgroup@remove-emax.dk> wrote:

> Lasse Hillerøe Petersen wrote:
>
> > Jeg vil stadig gerne vide det hvis jeg tager fejl mht PHP. Uden at
> > blive beskudt med fabelagtige tåbeligheder som:
>
> Det er lidt svært at sige om du tager fejl, når du udtaler "Hvis PHP
> virkelig gør det du siger, så stinker PHP." Men PHP kan det, som Peters
> eksempel viser.

Nu har jeg lige gjort mig den ekstra ulejlighed at kigge lidt på PHP.
For første og forhåbentlig sidste gang.

http://www.php.net/manual/en/language.expressions.php
" PHP provides a full and powerful implementation of expressions, and
documenting it entirely goes beyond the scope of this manual."

Hvordan kan man i fuld alvor skrive sådan noget nonsens i en *reference*
manual? (Som jeg går ud fra det er, jeg kunne ikke finde andre.)

"The above examples should give you a good idea about what expressions
are and how you can construct useful expressions. Throughout the rest of
this manual we'll write expr to indicate any valid PHP expression."

Men man definerer ikke præcist hvad der er valid eller ej. Dvs man skal
gætte sig til semantikken af et udtryk. Det er ikke helt
dd if=/dev/random of=program bs=1234567 count=1
chmod +x program

men det snerper vist.

Næste afsnit, http://www.php.net/manual/en/language.operators.php:
"Note: Although ! has a higher precedence than =, PHP will still allow
expressions similar to the following: if (!$a = foo()), in which case
the output from foo() is put into $a."

Hvis jeg forstår det ret, er "!$a" altså i en lvalue kontekst den samme
lvalue som "$a", men resultatet er negationen af "$a". Jeg kan ikke
gennemskue om det er før eller efter assignment af $a, eller hvilken
lvalue der bliver assignet ved fx "$a != $b = foo()". "Manualen"
præciserer det ikke nærmere.

Perl er muligvis et ret bizart sprog på mange måder, men det her slår
alt.

I rest my case. PHP stinker.

-Lasse

---

Lasse Hillerøe Petersen wrote:

> I rest my case. PHP stinker.

Eller manualen gør? Det vil så være første gang, jeg hører det. Du må gerne
smide mig et link på en online manual over perl, der går fuldstændigt til
bunds i det sprog. Uanset om du koder perl, PHP, C++ eller andet, så er
hovedreglen at er du en elendig programmør, så bliver koden det også.
Pointeres i C++ kan være noget så powerfull... i hænderne på den rette, men
oftes ses det at programmøren mister overblikket og så er det en anden snak.
Endnu værre bliver det, når programmøren afsætter hukommelse og glemmer at
frigøre den igen, Mr. Malloc hærger og kan i værste fald bringe et system i
knæ...

Nå, denne er vist ikke videre Perl specifikt, og har ikke været det et par
postings, så mon ikke vi skal futte et andet sted hen, hvis den skal
forsætte?

--
Take Care
Kim Emax - Freelance programmør - opgaver modtages
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

On Sat, 16 Aug 2003 09:19:32 +0200,
Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> wrote:

> http://www.php.net/manual/en/language.expressions.php
> " PHP provides a full and powerful implementation of expressions, and
> documenting it entirely goes beyond the scope of this manual."
>
> Hvordan kan man i fuld alvor skrive sådan noget nonsens i en *reference*
> manual? (Som jeg går ud fra det er, jeg kunne ikke finde andre.)

Jeg finder det ikke mærkeligt. Sprog hvor implementationen netop er
sprogets specifikation (i (C) kildekode) har jeg set mere end en gang.
Perl dækker vist også dette. At det så ikke er den metode jeg vil
benytte til at designe sprog er noget helt andet. Hvad jeg fandt
underligt i PHP var at for visse library-calls galdt foo(exp) ikke, men
man var nødt til at lave a = exp; foo(a). Det tyder på en uortogonal
parser og fortolker.

> Hvis jeg forstår det ret, er "!$a" altså i en lvalue kontekst den samme
> lvalue som "$a", men resultatet er negationen af "$a". Jeg kan ikke
> gennemskue om det er før eller efter assignment af $a, eller hvilken
> lvalue der bliver assignet ved fx "$a != $b = foo()". "Manualen"
> præciserer det ikke nærmere.
>
> Perl er muligvis et ret bizart sprog på mange måder, men det her slår
> alt.

Tjah, PHP har ikke en veldefineret semantik. Personligt programmerer jeg
det ikke særligt meget og jeg er sådan set også ligeglad med det sprog.
Jeg vil tro at folk der programmerer det enten lærer dets underligheder
eller benytter ''sikre'' konstruktioner de kan stole på. Der er masser
af eksempler på udefineret semantik i masser af sprog.

Jeg ville nok heller aldrig vælge Perl til større projekter end mine
100-liners. Men sådan er der jo så meget.

--
Jesper

---

On Mon, 18 Aug 2003 09:49:28 +0000 (UTC), Jesper wrote:

> Jeg ville nok heller aldrig vælge Perl til større projekter end mine
> 100-liners. Men sådan er der jo så meget.

Hvad vælger du i stedet, og hvorfor?


Mvh.

--
"Q: Are you happy? Adam Sjøgren
A: Yes. As an ashtray maybe." asjo@koldfront.dk

---

On Mon, 18 Aug 2003 12:14:36 +0200, Adam Sjøgren <spamtrap@koldfront.dk> wrote:
> On Mon, 18 Aug 2003 09:49:28 +0000 (UTC), Jesper wrote:
>
>> Jeg ville nok heller aldrig vælge Perl til større projekter end mine
>> 100-liners. Men sådan er der jo så meget.
>
> Hvad vælger du i stedet, og hvorfor?

Siden du spørger af interesse:

Jeg foretrækker at benytte Scheme til lidt større hacks. Bliver det
større endnu går jeg som regel over til Ocaml eller Standard ML.

Perl finder jeg anvendeligt som glue-sprog til mange mindre
systemadministrationsopgaver, hvor noget skal linkes sammen hurtigt.
sh-scripting er anvendeligt, hvis opgaverne i virkeligheden bare handler
om at batche et par unix-programmer sammen.

Hvorfor jeg vælger Scheme? Fordi det har en række sprogkonstruktioner
jeg foretrækker at bruge. Hvorfor Ocaml og SML? Fordi de er statisk
typede, har et uovertruffent modulsystem, og gør at man skal skrive
mindre kode for at gøre det samme som i andre sprog.

Hvorfor perl til mindre opgaver? Regulære udtryk er rare når man skal
pille i strenge, og dertil hjælper det at have regexps indbygget i
sprogets syntaks. Derudover hjælper det at have simple abstrakte
datatyper indbygget (lists, hashes, etc), så man hurtigt kan organisere
data. Hvis der er noget jeg savner er det at jeg i højere grad ville
ønske jeg kunne undgå at passe referencer til data rundt, men i stil med
Python eller Ruby kunne at passe data selv rundt[1].

sh-scripting hænger på hvad opgaverne. Jeg finder det som værende
overkill hvis opgaven i virkeligheden er at kalde 25 små programmer på
kommandolinien. Så virker Perl ikke så godt.

Jeg kan ikke lide Perl som sprog. Det er grimt, det er rodet, det
mangler ortogonale konstruktioner. Men - det gør tingene for en.

[1] og det er jo snyd, for det er implicit en ref du passer i disse
sprog.

--
Jesper

---

On Mon, 18 Aug 2003 12:32:16 +0000 (UTC), Jesper wrote:

> Siden du spørger af interesse:

Det gør jeg absolut. Tak for svaret.

> Jeg foretrækker at benytte Scheme til lidt større hacks. Bliver det
> større endnu går jeg som regel over til Ocaml eller Standard ML.

Hvordan definerer du små, lidt større og endnu større?

> Jeg kan ikke lide Perl som sprog. Det er grimt, det er rodet, det
> mangler ortogonale konstruktioner. Men - det gør tingene for en.

Jeg bliver for det meste forvirret når folk taler om ortogonalitet i
sprog (specielt når folk siger: "det er ikke helt ortogonalt" eller
lignende - det gør du ikke, men jeg forstår ikke rigtig hvad du mener
alligevel).

Gider du uddybe hvad du specifikt tænker på her?


Mvh.

--
"Q: Are you happy? Adam Sjøgren
A: Yes. As an ashtray maybe." asjo@koldfront.dk

---

On Mon, 18 Aug 2003 14:54:45 +0200, Adam Sjøgren <spamtrap@koldfront.dk> wrote:

>> Jeg foretrækker at benytte Scheme til lidt større hacks. Bliver det
>> større endnu går jeg som regel over til Ocaml eller Standard ML.
>
> Hvordan definerer du små, lidt større og endnu større?

Små: Alt hvad der kan hackes sammen på under en uges arbejde. Det drejer
sig om run-once programmer, systemadministrationsscripts og lignende.

Større: Et par ugers varighed. Ergo omkring 100-150 mandetimers arbejde.

Rigtigt store: Alt derudover.

Problemet er i virkeligheden at minimere tiden hvorfra man planligger et
program til at det står færdigt. Der er en lidt højere entry-level i SML
end i Perl eksempeltvist. Så små opgaver ville blive større i SML end
det er at få dem til at virke i Perl. Det væsentlige her er at man
hurtigt kan hive et par moduler fra CPAN. Desværre er kvaliteten af
CPAN-moduler ikke altid det man kunne ønske sig, så hvis man ønsker mere
kontrol over sit program foretrækker jeg at lave det meste af
algoritmerne/datastrukturerne selv. Og så er gevinsten ved Perl IMO mindre.

> Jeg bliver for det meste forvirret når folk taler om ortogonalitet i
> sprog (specielt når folk siger: "det er ikke helt ortogonalt" eller
> lignende - det gør du ikke, men jeg forstår ikke rigtig hvad du mener
> alligevel).
>
> Gider du uddybe hvad du specifikt tænker på her?

Gerne. Begrebet er i høj grad misbrugt, så mærk dig det når du hører
det. Desuden er begrebet ikke veldefineret indenfor datalogi. I
matematik betyder det ''vinkelret på'' og det er denne analogi der
overføres. Hvis et værktøjssæt er ortogonalt supplerer det hinanden. Der
er få måder at skrive det samme stykke kode på (forudsat algoritmen
er den samme). Imidlertid er det stærkt subjektivt og svært at definere.
Desuden er det svært at argumentere for fordelene i visse tilfælde. Perl
tillader eksempeltvist både if(!...) og unless(...) foranstillet såvel
som bagvedstillet et statement. Men i visse tilfælde kan man argumentere
for dette giver mere læselige programmer. Et mere grelt eksempel ville
være et sprog hvor det i visse tilfælde ikke var lovligt at foretage en
! (not) operation på visse boolske værdier eller lignende. I Ruby og
Python er det eksempeltvist generaliseret at iterere over en
datastruktur, hvorimod der findes n forskellige funktioner i Perl til at
gøre det, der hver skal anvendes på sin måde.

Begrebet er lige så dårligt som Objektorienteret programmering,
Funktionel programmering og lignende. Når jeg hævder at sproget ikke er
ortogonalt mener jeg derfor at sprogets konstruktioner ikke i så høj
grad understøtter hinanden i et logisk samspil. Det er ikke
nødvendigvist et udtryk for at sproget er dårligt, men i højere grad et
udtryk for at sproget ikke er planlagt en gang for alle, men har
udviklet sig evolutionært over tid.

Den diamentrale modsætning til et sådant sprogdesign er SML, hvor hele
sproget er matematisk veldefineret. Det er veldefineret hvad der sker i
alle situationer og sproget er bevist værende ''sundt'' (sound). Det
fordrer mange forskellige implementationer af samme sprog (fordi man kan
læse sig til hvad sproget skal gøre i en bestemt situation og det er
veldefineret hvad der sker). Til gengæld bliver sproget også meget mere
maskinelt i sin syntaks og semantik. Jeg mener det er en fordel, men at
dømme efter den store anvendelse af Perl, C, C++ og lignende er det ikke
alle der deler den opfattelse.

I virkeligheden burde jeg nok i højere grad have givet udtryk for dette
i mit oprindelige indlæg, men nu har jeg så rettet op på det :)

--
Jesper

---

On Mon, 18 Aug 2003 17:09:48 +0000 (UTC), Jesper wrote:

> Gerne. Begrebet er i høj grad misbrugt, så mærk dig det når du hører
> det. Desuden er begrebet ikke veldefineret indenfor datalogi.

Det er derfor jeg spørger hvad _du_ mener med det

> I matematik betyder det ''vinkelret på'' og det er denne analogi der
> overføres.

Det er det jeg normalt tænker, når jeg læser det, og så bliver det
meget hurtigt meget lidt nemt at følge med i hvad folk egentlig mener
med det.

"Det er ikke så ortogonalt" - hmmm, enten er det vinkelret, eller også
er det ikke.

> Hvis et værktøjssæt er ortogonalt supplerer det hinanden. Der er få
> måder at skrive det samme stykke kode på (forudsat algoritmen er den
> samme).

Umiddelbart synes jeg at det er upraktisk i virkelighedens verden ikke
at have frihed til at formulere det samme på forskellige måder. Der er
lidt design lavet af en praktiker vs. en teoretiker i det.

Det er selvfølgelig ligegyldigt at have unless når man har if not, men
i mange situationer er det ene nemmere at læse end det andet (som du
også nævner) - og, for nu at citere en anden gammel traver: programmer
skrives primært for at andre mennesker skal læse dem, derefter for at
computere kan fortolke dem.

> Når jeg hævder at sproget ikke er ortogonalt mener jeg derfor at
> sprogets konstruktioner ikke i så høj grad understøtter hinanden i
> et logisk samspil.

Det er stadig for utydeligt til at det rigtigt giver mig et billede af
hvad det er du _egentlig_ mener.

[SML]

> Til gengæld bliver sproget også meget mere maskinelt i sin syntaks
> og semantik. Jeg mener det er en fordel, men at dømme efter den
> store anvendelse af Perl, C, C++ og lignende er det ikke alle der
> deler den opfattelse.

Jeg er efterhånden landet i at synes, at selvom jeg godt kan se det
smukke i at konstruere et sprog der er slankt, elegant og minimalt, så
er det ikke særligt ofte at det resulterende sprog også er et hvor
mange mennesker kan udtrykke sig i praksis - og dermed bruge det i
praksis...


Mvh.

--
"Watch it man, there's a beverage here" Adam Sjøgren
asjo@koldfront.dk

---

spamtrap@koldfront.dk (Adam Sjøgren) writes:

> "Det er ikke så ortogonalt" - hmmm, enten er det vinkelret, eller også
> er det ikke.

Jeg opfatter normalt begrebet "ortogonalt" som uafhængigt, hvilket
giver bedre mening i vores verden. Vinkelret lugter lidt for meget af
geometri :)

> Jeg er efterhånden landet i at synes, at selvom jeg godt kan se det
> smukke i at konstruere et sprog der er slankt, elegant og minimalt, så
> er det ikke særligt ofte at det resulterende sprog også er et hvor
> mange mennesker kan udtrykke sig i praksis - og dermed bruge det i
> praksis...

Ind kommer begrebet "runtimebibliotek" :)

Perls problem er at den syntaks der er opfundet til at håndtere
refs - altså skalarværdier som pointere til forskellige strukturer -
meget nemt bliver tung at læse. Kombinerer man dette med et par
regulære udtryk, er vi først rigtigt hjemme.

Jeg kan ikke helt lure fra http://dev.perl.org/perl6/apocalypse/
hvorvidt at Perl6 bliver bedre, men det er min opfattelse at der er en
hel del ting der bliver mere læsevenlige.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

jlouis@pc-063.diku.dk (Jesper Louis Andersen) writes:
>>> Jeg foretrækker at benytte Scheme til lidt større hacks. Bliver det
>>> større endnu går jeg som regel over til Ocaml eller Standard ML.

Du vil da ikke påstå at du vil kaste SML efter store multimands
projekter ude i virkeligheden?

Og jeg troede det var svært at finde gode Perl-folk...

> Den diamentrale modsætning til et sådant sprogdesign er SML, hvor hele
> sproget er matematisk veldefineret.

SML er jo proppet med overflødige konstruktioner. Hvis du vil have
ortogonalt og veldefineret vil jeg anbefale lambdakalkylen:

<Exp> ::= <ident> |
lambda <ident> . <Exp> | -- function abstraction
<Exp> <Exp> | -- function application
( <Exp> )

Den kan det hele. God fornøjelse.

Dataloger har mange kvaliteter, men sprogdesign er ikke nødvendigvis
en af dem. Programmører er ikke maskiner.
--
Lars Balker Rasmussen Consult::Perl

---

In article <0f4r0elmrf.fsf@laphroaig.balker.org>, Lars Balker Rasmussen wrote:

> Du vil da ikke påstå at du vil kaste SML efter store multimands
> projekter ude i virkeligheden?
>
> Og jeg troede det var svært at finde gode Perl-folk...

Hvorfor egentlig ikke? ML er da fornuftige sprog med fornuftige
implementationer. Du har ret i, at gode programmoerer desvaerre er en
mangelvare af rang.

> SML er jo proppet med overflødige konstruktioner. Hvis du vil have
> ortogonalt og veldefineret vil jeg anbefale lambdakalkylen:

Du er inde paa noget vaesentligt. Alle sprog vil uden tvivl have en base
som de benytter sig af. For imperative sprogs vedkommende er de jo ''bare''
en abstraktion ovenpaa en Von-neumann maskine. For funktionelle sprogs
vedkommende er de bare en abstraktion paa lambdakalkylen.

> Dataloger har mange kvaliteter, men sprogdesign er ikke nødvendigvis
> en af dem. Programmører er ikke maskiner.

Nej, praecis. Det er ogsaa derfor at en raekke sprog saasom blandt andet
perl klarer sig saa godt vil jeg tro. Men det retter ikke op paa at
sproget som design ikke er koent. I virkeligheden vil jeg opfatte
programmering som kunst og sproget som medie - men det er en helt anden
snak.

--
j.

---

Jesper Louis Andersen <jlouis@nospammongers.org> wrote in message news:<slrnbk4h73.viv.jlouis@miracle.mongers.org>...
>
> > Dataloger har mange kvaliteter, men sprogdesign er ikke nødvendigvis
> > en af dem. Programmører er ikke maskiner.
>
> Nej, praecis. Det er ogsaa derfor at en raekke sprog saasom blandt andet
> perl klarer sig saa godt vil jeg tro. Men det retter ikke op paa at
> sproget som design ikke er koent.

Sprog som Dansk og Engelsk er heller ikke "kønt designet" - men
vældigt effektivt for
mennesker at kommunikere med.


- ask (som burde få sat gnus op til at snakke med dk.* grupperne
igen)

--
http://www.askbjoernhansen.com/

---

On 18 Aug 2003 23:29:41 +0200, Thorbjoern wrote:

> Jeg opfatter normalt begrebet "ortogonalt" som uafhængigt, hvilket
> giver bedre mening i vores verden. Vinkelret lugter lidt for meget
> af geometri :)

Ja, det gør det nok. Jeg hørte udtrykket først i matematik og er
matematik-fascineret (desværre ikke ditto begavet), så har jeg svært
ved at abstrahere fra det.

> Perls problem er at den syntaks der er opfundet til at håndtere refs
> - altså skalarværdier som pointere til forskellige strukturer -
> meget nemt bliver tung at læse. Kombinerer man dette med et par
> regulære udtryk, er vi først rigtigt hjemme.

Tjoh, det kan være jeg ikke lægger mærke til det fordi jeg bare har
vænnet mig til status quo. Hvad mener du mere specifikt?

> Jeg kan ikke helt lure fra http://dev.perl.org/perl6/apocalypse/
> hvorvidt at Perl6 bliver bedre, men det er min opfattelse at der er
> en hel del ting der bliver mere læsevenlige.

Jeg må indrømme at jeg har været for doven til at sætte mig ind i
hvordan planerne udvikler sig...


Mvh.

--
"Someone said ``look, it's Milli Vanilli!'' but Adam Sjøgren
that's totally unfair to Milli Vanilli: at least asjo@koldfront.dk
they danced."

---

spamtrap@koldfront.dk (Adam Sjøgren) writes:

> Tjoh, det kan være jeg ikke lægger mærke til det fordi jeg bare har
> vænnet mig til status quo. Hvad mener du mere specifikt?

Regulære udtryk (i den gamle syntaks) er svære at læse. Perl 5
konstruktionerne med @{$[blabla]}->[muh] kan også være svære at læse
hvis man ikke er øvet.

> Jeg må indrømme at jeg har været for doven til at sætte mig ind i
> hvordan planerne udvikler sig...

De laver det hele om. Herunder at de bygger en ny virtuel maskine til
at køre Perl på - når denne virtuelle maskine bliver tilgængelig i en
Java udgave bliver Perl interessant for mig igen til andet end det
hurtige hovsa-hack.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Thorbjoern Ravn Andersen <nospam0000@unixsnedkeren.dk> writes:

> spamtrap@koldfront.dk (Adam Sjøgren) writes:
>
>> Tjoh, det kan være jeg ikke lægger mærke til det fordi jeg bare har
>> vænnet mig til status quo. Hvad mener du mere specifikt?
>
> Regulære udtryk (i den gamle syntaks) er svære at læse. Perl 5
> konstruktionerne med @{$[blabla]}->[muh] kan også være svære at læse
> hvis man ikke er øvet.

Nu er det lang tid siden jeg læste Apocalypsen om regulære udtryk, men
jeg mindes at der var en del notation jeg ikke brød mig om og nogle få
tilføjelser jeg brød mig om.

Jeg synes først det bliver rodet når man begynder at anvende Extended
Patterns (<!?patter) og den slags. Jeg er begyndt at bruge (:?pattern)
men kun fordi det gør den efterfølgende kode lettere.

Det er også lang tid siden at jeg har brugt noget der bare minder om
@{$[blabla]}->[muh]. Det kan måske være fordi jeg er øvet nok til at
vide hvornår og hvordan de undgås?

>> Jeg må indrømme at jeg har været for doven til at sætte mig ind i
>> hvordan planerne udvikler sig...
>
> De laver det hele om. Herunder at de bygger en ny virtuel maskine til
> at køre Perl på -

Parrot er på en gang det jeg finder mest interessant og mindst
interesant. Den er interessant fordi den er et mere selvstændigt
projekt og ikke bare en obskur intern del af perl. Dette giver
mulighed for ting som Ponie, ruby og python under parrot.

Som perlprogrammør finder jeg parrot uinteressant. Det er ikke noget
jeg kommer til at se på. Det eneste jeg her er interesseret i ville
være om den var hurtigere, havde et mere effektivt hukommelsesforbrug
eller på anden måde var bedre end den nuværende. Hvordan og hvorfor
ville være ligemeget.


Jeg ryster hver gang jeg læser en Apocalyse eller en Exegesis. Jeg får
altid den fornemmelse at perl6 bliver et overdesignet sprog og hårdt
ramt af second system effects. *Men* disse dokumenter forkuserer
selvfølgelig på ændringerne og er derfor (forhåbentlig) værre end
resultatet.

Nåja, og så mener jeg at '-> $x { $x + 1 }' ser forkert ud. Det burde
have heddet '$x -> { $x + 1 }' eller endnu bedre '\$x.$x+1'. Og lige
meget hvad de siger så vender Schwartzian Transform den rigtige vej.


Jeg har det lidt med Perl6 som jeg har det med GPL3 - det giver mig
marreridt.

--
Peter Makholm | Yes, you can fight it, but in the end the ultimate
peter@makholm.net | goal of life is to have fun
http://hacking.dk | -- Linus Torvalds

---

Peter Makholm <peter@makholm.net> writes:

> Nu er det lang tid siden jeg læste Apocalypsen om regulære udtryk, men
> jeg mindes at der var en del notation jeg ikke brød mig om og nogle få
> tilføjelser jeg brød mig om.

Jeg har ingen anelse om hvorvidt det bliver bedre, men hvis det bliver
lettere at læse er man i mine øjne nået langt.

> Det er også lang tid siden at jeg har brugt noget der bare minder om
> @{$[blabla]}->[muh]. Det kan måske være fordi jeg er øvet nok til at
> vide hvornår og hvordan de undgås?

Måske. Eller også har du ikke haft datastrukturer der var
komplicerede nok

> Parrot er på en gang det jeg finder mest interessant og mindst
> interesant. Den er interessant fordi den er et mere selvstændigt
> projekt og ikke bare en obskur intern del af perl. Dette giver
> mulighed for ting som Ponie, ruby og python under parrot.

Hvis det hele resulterer i en ny Open Source virtuel maskine som kan
afvikle en masse sprog, og som det er nemt at portere til, er det hele
bøvlet værd.

Den seneste Microsoft orm har tydeligt vist for mig at den eneste måde
man kan helgardere sig på i en homozygotisk computerverden, er ved at
kontrollere den kode der kører. Signeret kode er ikke nok - der skal
aktivt kontrolleres. Det kan kun lade sig gøre i en virtuel maskine.

Jeg har startet en tråd i sslug.itpolitik. Det lader ikke til at det
trigger nogen.

> Jeg ryster hver gang jeg læser en Apocalyse eller en Exegesis. Jeg får
> altid den fornemmelse at perl6 bliver et overdesignet sprog og hårdt
> ramt af second system effects. *Men* disse dokumenter forkuserer
> selvfølgelig på ændringerne og er derfor (forhåbentlig) værre end
> resultatet.

Uanset hvad, så er det resultatet af MANGE menneskers arbejde, så
chancen for at det bliver nogen fås kæpheste er lille.

> Jeg har det lidt med Perl6 som jeg har det med GPL3 - det giver mig
> marreridt.

Sådan er vi så forskellige. Jeg afventer Perl6 og ser. Indtil videre
er det ren vaporware.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

In article <kkada657p9.fsf@mimer.null.dk>,
Thorbjoern Ravn Andersen <nospam0000@unixsnedkeren.dk> wrote:

> Den seneste Microsoft orm har tydeligt vist for mig at den eneste måde
> man kan helgardere sig på i en homozygotisk computerverden, er ved at
> kontrollere den kode der kører. Signeret kode er ikke nok - der skal
> aktivt kontrolleres. Det kan kun lade sig gøre i en virtuel maskine.

(ADVARSEL! rablen forude! Rable-intolerante bedes overspringe!)

Den seneste Microsoft orm har tydeligt vist for mig, at mail klienter
ikke skal kunne bringes til at eksekvere executable content. Efter min
mening har Microsoft gjort en ubodelig skade på samfundet ved at tillade
det. Nu hænger vi (i hvert fald nogen[1]) på den, og en masse mennesker
tjener tykt på at lave antivirus og filtre, og har derfor reelt ingen
interesse i en egentlig løsning på problemet.

Men mht at kode skal kontrolleres (fordi signeret kode ikke nødvendigvis
er venlig kode) har du naturligvis ret. Du har dog ikke ret i, at det
kun kan lade sig gøre i en virtuel maskine, i hvert fald ikke hvis du
dermed mener .NET eller Parrot (eller JVM.) FreeBSD jails eller
VMWare-agtige ting burde kunne gøre det samme. Men så er der jo altså
desværre stadigvæk moralen fra Ken Thompsons Turing Award tale
<http://www.acm.org/classics/sep95/>. Så kan vi køre historien helt ud,
og så ender det med at man knap kan stole på en gammel Remington
skrivemaskine.

Eller det ender med et totalkontrolleret samfund, som ikke reelt vil
kunne fungere, men som da har været forsøgt. Stalins "Tillid er godt,
men kontrol er bedre" holder altså heller ikke i længden, for det vil
ende med at systemet kontrollerer mennesket. (OK, så holder den
alligevel i længden, men med ubehagelige konsekvenser.)

Så måske er "trust", med signaturer osv alligevel den eneste reelle vej
frem. Men det nytter ikke at det er makroniveau-trust, hvor
samfundet/Microsoft fortæller dig (via dit OS) at du naturligvis altid
kan stole på Microsoft. Trust er efter min mening bedst når afstanden
mellem truster og trustee er lille, og naturligvis må begge være
ansvarlige personer. Dvs jeg stoler på X. Hvis det så mod forventning
viser sig at jeg ikke kunne stole på X, så er jeg tæt nok på ham, til at
jeg kan komme til at kyle en low-tech brosten i nakken på ham. Det er en
del sværere med Bill Gates, eller en upersonlig entitet som Microsoft -
eller "staten" - eller "TDC".

Så måske kunne et bedre motto end Stalins være:
"Tillid er godt nok, og hvis ikke, er hævnen sød."[3][4]

Og så er det nok vigtigst af alt at huske, at tillid drejer sig om
relationer mellem mennesker, ikke maskiner.

-Lasse

[1] Jeg læser personligt mail med grep og more, så jeg er uden for
fare.[2]
[2] Og dog, det koster også _mig_ penge, som skatteyder, når det
offentlige rammes af virus pga Microsofts dispositioner, og tvinges til
at smide gode penge efter dårlige i forsøget på at holde deres antivirus
update, i stedet for at bruge et relativt usårligt mailsystem, som oven
i købet er gratis.
[3] Jeg _tror_ nok, at det er en lære, man også kan uddrage af Max
Stirners _Der Einzige und sein Eigentum_, en bog flere mennesker burde
læse, hvis vi vil undgå at blive systemslaver i en alt for nær fremtid.
[4] Mere korrekt ville det lyde: "Tillid er godt nok, og hvis ikke, er
hævnen forhåbentlig sød, ellers har jeg tabt." Man må i sidste ende selv
stå til ansvar for sin tillid. Og kan man ikke stole på sig selv, har
man tabt.

---

Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:

> [1] Jeg læser personligt mail med grep og more, så jeg er uden for
> fare.[2]

Understøtter din terminalemulator vt100 koder? Så er du skam også
sårbar...
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:

> Den seneste Microsoft orm har tydeligt vist for mig, at mail klienter
> ikke skal kunne bringes til at eksekvere executable content. Efter min
> mening har Microsoft gjort en ubodelig skade på samfundet ved at tillade
> det. Nu hænger vi (i hvert fald nogen[1]) på den, og en masse mennesker
> tjener tykt på at lave antivirus og filtre, og har derfor reelt ingen
> interesse i en egentlig løsning på problemet.

Jeg kan se en meget stor fordel i at det er _muligt_ at aktivere andre
programmer som håndterer datafiler direkte inde fra et postprogram.
Se PDF filer og den slags.

Spørgsmålet er hvornår det er eksekverbart og det lader til at være
her at Microsoft har fejlet. Om det er af mangel på omtanke eller for
at gøre det så nemt som muligt, vil jeg ikke tage stilling til, men
det kan da undre at man kan køre en pauseskærm direkte fra
postprogrammet. Ligeledes med PIF-filer.

> Men mht at kode skal kontrolleres (fordi signeret kode ikke nødvendigvis
> er venlig kode) har du naturligvis ret. Du har dog ikke ret i, at det
> kun kan lade sig gøre i en virtuel maskine, i hvert fald ikke hvis du
> dermed mener .NET eller Parrot (eller JVM.) FreeBSD jails eller
> VMWare-agtige ting burde kunne gøre det samme. Men så er der jo altså
> desværre stadigvæk moralen fra Ken Thompsons Turing Award tale
> <http://www.acm.org/classics/sep95/>. Så kan vi køre historien helt ud,
> og så ender det med at man knap kan stole på en gammel Remington
> skrivemaskine.

Tiltro (min bedste oversættelse af "trust") er altid afgørende, ikke
bare i computere. Du stoler på at dem der har lavet din bil (og ikke
mindst den modkørende bilists bil) kan deres kram og at hjulet ikke
lige falder af. Vi er - med rette - vænnet til at ting fungerer og
holder mindst garantiperioden ud. Vi er - med urette - vænnet til at
software er købt som beset og uden garanti, kombineret med at
Microsoft fokuserer på at sælge nye versioner i stedet for at rette
fejl. (se fx http://www.cantrip.org/nobugs.html).

Resultatet er hvad vi ser i disse dage.

At man så har mindre tiltro til Microsoft end til andre på grund af
disse ting, som klart og tydeligt skyldes urettede fejl i deres
produkter, betyder ikke at man skal hoppe i den anden grøft og ikke
stole på nogen som helst. Det vil formentlig betyde at du ikke tør
skrive et svar og det ville være trist.

Jeg har set Thompsons tale brugt i undervisningsbrug og pointen er
rigtig god.

(Han taler om hvordan man kan få en C compiler til at introducere
trojanske heste i uskyldig kode, herunder at viderbringe denne
mulighed til nye C compilere oversat af den gamle, uden det er til at
opdage. Moralen: Stoler du på din compiler?).

> Så måske er "trust", med signaturer osv alligevel den eneste reelle vej
> frem. Men det nytter ikke at det er makroniveau-trust, hvor
> samfundet/Microsoft fortæller dig (via dit OS) at du naturligvis altid
> kan stole på Microsoft. Trust er efter min mening bedst når afstanden
> mellem truster og trustee er lille, og naturligvis må begge være
> ansvarlige personer. Dvs jeg stoler på X. Hvis det så mod forventning
> viser sig at jeg ikke kunne stole på X, så er jeg tæt nok på ham, til at
> jeg kan komme til at kyle en low-tech brosten i nakken på ham. Det er en
> del sværere med Bill Gates, eller en upersonlig entitet som Microsoft -
> eller "staten" - eller "TDC".

Du har lige sat fingere præcis på de forskellige krypteringsmetoder
til identifikation. Hvem stoler man på til at begynde med? I Danmark
_kunne_ det måske være staten, men hverken Microsoft eller TDC i mine øjne.

> Og så er det nok vigtigst af alt at huske, at tillid drejer sig om
> relationer mellem mennesker, ikke maskiner.

Problemet er hvordan man finder ud af at det virkelig er disse
mennesker og formidler det på en effektiv måde.

> stå til ansvar for sin tillid. Og kan man ikke stole på sig selv, har
> man tabt.

Jeg kan høre at du allerede har svære problemer, selv inden der kommer
computerprogrammer på bordet :)

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

In article <kkn0e3qq28.fsf@mimer.null.dk>,
Thorbjoern Ravn Andersen <nospam0000@unixsnedkeren.dk> wrote:

> Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:
>
> > Den seneste Microsoft orm har tydeligt vist for mig, at mail klienter
> > ikke skal kunne bringes til at eksekvere executable content. Efter min
> > mening har Microsoft gjort en ubodelig skade på samfundet ved at tillade
> > det. Nu hænger vi (i hvert fald nogen[1]) på den, og en masse mennesker
> > tjener tykt på at lave antivirus og filtre, og har derfor reelt ingen
> > interesse i en egentlig løsning på problemet.
>
> Jeg kan se en meget stor fordel i at det er _muligt_ at aktivere andre
> programmer som håndterer datafiler direkte inde fra et postprogram.
> Se PDF filer og den slags.

Nu har jeg aldrig nærlæst specifikationerne for PDF, men jeg har da
kodet en smule PostScript, og jo, i princippet kunne man vel nok sende
noget subversiv kode til en printer og få den til at gøre noget slemt.
Men jeg tvivler på at Acrobat tillader PDF-dokumenter at røre ved
maskinens filsystem direkte.

Jeg erindrer med gru skiftet fra Word 5 til Word 6 (Macintosh). Selv
fortsatte jeg med Word 5.1a med Word6 konvertering, men andre blev
hurtigt ofre for de første macroviruser. Og de første jeg så af slagsen
var endda relativt harmløse. Men husker jeg ret, var det først en senere
version, der gjorde det muligt at slå makroer FRA. Ikke at nogen gjorde
det, for med AUs nye brevpapir var alt allerede lagt an til, at makroer
var noget man var tvunget til at anvende.

Tænk hvis jeg kunne tvinge dig til at udføre
"su root -c 'cd / ; rm -rf .'"

bare ved at lave en passende header i denne artikel, for eksempel. Men
det kan jeg ikke, og hvorfor? Fordi den problemstilling har været kendt
på Internettet stort set altid, og derfor har man bevidst valgt at
undlade at implementere sådan funktionalitet.

Nu er det _meget_ længe siden jeg læste news på Unix med nn, men jeg
husker at jeg har downloadet shell-arkiver fra comp.sources.unix; og det
forekommer mig, at man fik en ret entydig advarsel om at det var
forbundet med en risiko.

> produkter, betyder ikke at man skal hoppe i den anden grøft og ikke
> stole på nogen som helst. Det vil formentlig betyde at du ikke tør
> skrive et svar og det ville være trist.

Det har jeg heller ikke givet udtryk for, mener jeg. Men det er
afgørende at man selv bevidst vælger hvornår man udviser tillid, og har
de nødvendige forudsætninger for at træffe det valg. Folk er generelt
ikke vidende nok til at træffe det valg mht Microsoft, og ved at vælge
MS overlader de så efterfølgende beslutningen om tillid til mangelfuld
software. Jeg vil ikke give dig ret i at der er tale om urettede fejl;
der er så vidt jeg kan se tale om et fuldstændigt bevidst fravalg af
sikkerhed fra Microsofts side.

> Du har lige sat fingere præcis på de forskellige krypteringsmetoder
> til identifikation. Hvem stoler man på til at begynde med? I Danmark
> _kunne_ det måske være staten, men hverken Microsoft eller TDC i mine øjne.

"Staten" er mange ting; der er lovene, institutionerne, bureaukratiet,
og selvfølgelig "Magten"s "treenighed": regeringen, folketinget og
domstolene. Men i kraft af at "staten" ikke selv besidder nogen
kompetence mht kryptering, signaturer og identifikation, er vi tilbage
til at hvis vi stoler på staten, stoler vi implicit på dem staten stoler
på. Og det er aldeles ikke betryggende: staten stoler jo tydeligvis på
både Microsoft og TDC.

Mht dit spørgsmål "hvem stoler man på til at begynde med" er svaret -
hvis man sætter det i en lidt anden kontekst - ret enkelt, og egentlig
måske også fundamentalt: sine forældre. Men så er det man forhåbentlig
bliver klogere

Men det er gennem de direkte sociale relationer at man opbygger et net
af tillid. Problemerne opstår når disse relationer formaliseres i
systemer, og disse systemer så tillægges større væsentlighed end de
konkrete relationer de faktisk bare er en ufuldstændig abstraktion af.

Hvad nytter det at vi alle er lige for loven, hvis loven den er skæv?
Eller hvis man selv er - og/eller gerne vil være - lidt skæv?

> Problemet er hvordan man finder ud af at det virkelig er disse
> mennesker og formidler det på en effektiv måde.

Det er efter min bedste overbevisning umuligt at lave et system til
dette som ikke indeholder huller og problemer. Men det værste er, at der
sikkert findes mange dataloger som ikke deler min overbevisning, og
forsøger at konstruere sådanne systemer, og sælger dem til magthaverne
som "ufejlbarlige". Magthaverne har generelt ikke den nødvendige indsigt
i videnskab til at være opmærksomme på at der er en implicit betingelse.
Og så risikerer vi den slags situationer som SF-genren så ofte har
beskrevet, fx kontormanden i _BRAZIL_, som bliver offer for en flueklat.
Eller MINIHIS fra _1984_.

> > stå til ansvar for sin tillid. Og kan man ikke stole på sig selv, har
> > man tabt.
>
> Jeg kan høre at du allerede har svære problemer, selv inden der kommer
> computerprogrammer på bordet :)

Det må du vist lige uddybe hvad du mener med? Ellers ved jeg jo ikke om
jeg skal føle mig fornærmet!

(FUT: Poster, jeg vil gerne fortsætte diskursen på tomandshånd, og det
er vist ikke ret relevant for nyhedsgruppen.)

-Lasse

---

Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:

> (FUT: Poster, jeg vil gerne fortsætte diskursen på tomandshånd, og det
> er vist ikke ret relevant for nyhedsgruppen.)

Så er det hurtigere og nemmere at koordinere det med at Balker
indkalder - man bliver så TØRSTIG. Hvis nu det er foranlediget af at
man skal være der, kunne det være at det lykkes ham DENNE gang at
lægge det på et tidspunkt hvor jeg kan.

Iøvrigt kan han så invitere Daisy med - nu er anledningen jo hjemme.
"Deres Majestæt - aarhus.pm vil gerne se dem til en lille
højtidelighed. Vi stoler på at De kommer".
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

In article <kkk7914qm0.fsf@mimer.null.dk>, Thorbjoern Ravn Andersen wrote:
> Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> writes:
>
>> (FUT: Poster, jeg vil gerne fortsætte diskursen på tomandshånd, og det
>> er vist ikke ret relevant for nyhedsgruppen.)
>
> Så er det hurtigere og nemmere at koordinere det med at Balker
> indkalder - man bliver så TØRSTIG. Hvis nu det er foranlediget af at
> man skal være der, kunne det være at det lykkes ham DENNE gang at
> lægge det på et tidspunkt hvor jeg kan.
>
Det vil så give anledning til en faglig diskussion til et aarhus.pm
møde, hvilket vi nok må indrømme er uholdbart.


--
Erwin Lansing, FreeBSD ports monkey - abe.fnidder.dk