> On 14 Kwi, 15:50, "kenobi" <p...@p...onet.pl> wrote:

>

> > nie mam czasu ani checi na zapoznawanie sie kernelem linuksa - skoro wiesz

> > o czym mowisz to moze opowiesz jak to programisci c dziargaja "o o" w linux

> Uchwyt pliku, id procesu, socket....

> Pozdrawiam

whatever, musze uwazac aby nie umrzec z nudow (albo od nudnosci)
od tego 'oo' <bynajmniej nie zart - realne zagrozenie> ;
rano mialem jakis zaczatek drobnego pomyslu - powroce do c2 to poczuje sie
lepiej ;-)

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

A. L. wrote:

> On Thu, 14 Apr 2011 17:12:53 +0200, Michal Kleczek <k...@g...com>
> wrote:
>
>>Anegdota:
>>od razu zapuscilem gugla na "z language" i dostalem linki do wikipedii.
>>Poniewaz jest to zwiazane z "formal methods" seria odnosnikow zaprowadzila
>>mnie do http://en.wikipedia.org/wiki/B-Method - wymyslonej przez tegoz
>>samego autora co Z. Tam przeczytalem ze:
>>"B method has been used in some major safety-critical system applications
>>in Europe (such as in Paris Métro Line 14 and Ariane 5 rocket)." - no, w
>>koncu to metody formalne - do hardkorowych zastosowan.
>>I natychmiast mi sie przypomnialo o wypadku
>>http://en.wikipedia.org/wiki/Ariane_5_Flight_501
>>spowodowanym przez blad w oprogramowaniu.
>>
>>Ehh... zycie jest okrutne.
>
> Proponuje postudiowac DOKLADNIE przyczyny wypadku Ariane 5.

Postudiowalem, a powyzsze bylo tylko anegdota (celem tak naprawde bylo
posmianie sie ze stereotypow w rodzaju "OO - dobrze", "formal methods -
niezawodnie). Ale:

> Problem
> polegal na tym ze do Ariane 5 zastosowano system nawigacyjny od Ariane
> 4 ktory byl zaprojektowany na mniejsze przyspieszenia niz Ariane 5
> mogla osiagac podczas startu.
>
> Trudno w tym przypadku obwiniac sofrwate - software zachowal sie
> prawidlowo. Gdy liczby otrzymywane z systemu nawigacyjnego
> przekroczyly dopuszczalny zakres, komputer wylaczyl system
> nawigacyjny. Zgodnie ze specyfikacja.

To jakies waskie pojmowanie "prawidlowego zachowania oprogramowania".

Niewatpliwie wypadek byl spowodowany wadliwym dzialaniem systemu
komputerowego. Co wiecej - nie byla to awaria sprzetu (tzn. nic sie nie
spalilo, ani tez nie nastapila np. przypadkowa zmiana zawartosci pamieci),
lecz wadliwe dzialanie oprogramowania, ktore nie bylo przygotowane na
obsluge rzeczywistych danych wejsciowych. Nie nazwalbym tego "software
zachowal sie prawidlowo". To, ze zachowal sie zgodnie z jakas tam
specyfikacja nie oznacza, ze zachowal sie prawidlowo.

Operacja sie udala, pacjent zmarl. MSPANC

>
> Nie znam formalnych metod ktore sprawdzalyby poprawnosc i logike
> zalozen projektowych.
>

Czyli stosowanie metod formalnych nie zapobieglo wypadkowi.
Nie znam sie na metodach formalnych, ale wydawalo mi sie, ze stosowanie ich
ma zapobiegac pojawianiu sie bledow zarowno w implementacji jak i
_specyfikacji wymagan_ .

--
Michal

do góry

On Thu, 14 Apr 2011 21:13:24 +0200, Michal Kleczek <k...@g...com>
wrote:

>
>To jakies waskie pojmowanie "prawidlowego zachowania oprogramowania".
>
>Niewatpliwie wypadek byl spowodowany wadliwym dzialaniem systemu
>komputerowego. Co wiecej - nie byla to awaria sprzetu (tzn. nic sie nie
>spalilo, ani tez nie nastapila np. przypadkowa zmiana zawartosci pamieci),
>lecz wadliwe dzialanie oprogramowania, ktore nie bylo przygotowane na
>obsluge rzeczywistych danych wejsciowych. Nie nazwalbym tego "software
>zachowal sie prawidlowo". To, ze zachowal sie zgodnie z jakas tam
>specyfikacja nie oznacza, ze zachowal sie prawidlowo.
>

Software zachowuje sie prawidlowo jezeli dziala zgodnie ze
specyfikacja. Specyfikacja moze byc nieprawilowa.


>Operacja sie udala, pacjent zmarl. MSPANC
>
>>
>> Nie znam formalnych metod ktore sprawdzalyby poprawnosc i logike
>> zalozen projektowych.
>>
>
>Czyli stosowanie metod formalnych nie zapobieglo wypadkowi.
>Nie znam sie na metodach formalnych, ale wydawalo mi sie, ze stosowanie ich
>ma zapobiegac pojawianiu sie bledow zarowno w implementacji jak i
>_specyfikacji wymagan_ .

Zalezy gdzie sie zaczyna owa "specyfikacja". W przypadku Ariadne 5 byl
blad ludzki: nie powinno sie adaptowac modulu z Ariadne 4. Natomiast
nei wiem czy specyfikacja porgramu mowiaca ze komputer ma byc
wylaczony gdy zakres liczb zostanie przekroczony byla specyfikacja
sensowna czy nie. Takie rzeczy nie poddaje sie zadnym formalnym
sprawdzianom.

A.L.

do góry

Mariusz Marszałkowski wrote:

>> nie mam czasu ani checi na zapoznawanie sie kernelem linuksa - skoro
>> wiesz o czym mowisz to moze opowiesz jak to programisci c dziargaja "o o"
>> w linux
> Uchwyt pliku, id procesu, socket....
> Pozdrawiam

Z tego co ja dotychczas widziałem, wielu miłośników programowania
obiektowego nie lubi korzystać bezpośrednio z deskryptora pliku, uważając to
za zbyt "niskopoziomowe" i koniecznie trzeba opakować to w jakiś obiekt-
zaciemniacz intencji programisty.
Dlatego do "programowania obiektowego" tego nie zaliczyłem.

do góry

Wojciech Jaczewski wrote:

> Mariusz Marszałkowski wrote:
>
>>> nie mam czasu ani checi na zapoznawanie sie kernelem linuksa - skoro
>>> wiesz o czym mowisz to moze opowiesz jak to programisci c dziargaja "o
>>> o" w linux
>> Uchwyt pliku, id procesu, socket....
>> Pozdrawiam
>
> Z tego co ja dotychczas widziałem, wielu miłośników programowania
> obiektowego nie lubi korzystać bezpośrednio z deskryptora pliku, uważając
> to za zbyt "niskopoziomowe" i koniecznie trzeba opakować to w jakiś
> obiekt- zaciemniacz intencji programisty.

Wszystko sie zgadza, tylko jest dokladnie odwrotnie - gdyby API do systemu
bylo zrobione w jakims porzadnym obiektowym jezyku programowania, zaden
"deskryptor pliku" zaciemniajacy intencje programisty nie bylby potrzebny.
On jest potrzebny _wlasnie_ dlatego, ze koncepcje obiektowe implementuje sie
w jezyku, ktory OO nie wspiera.

--
Michal

do góry

Andrzej Jarzabek wrote:

>> Chciałem. Opamiętanie się, zajęło mi około dwa lata (pracy
>> zarobkowej + własnych eksperymentów).
>
> Wybacz, ale po pierwsze to co piszesz nie przekonuje mnie,

Cóż poradzić.

>> Stosowanie rozwiązań modnych ma swoje zalety, ale czasem
>> warto modę odrzucić.
>
> Czasem warto też myśleć o inżynierii w kategoriach innych niż moda.

W takim razie co innego niż moda sprawia, że programowanie obiektowe jest
tak popularne?

>> > klepiąc kod niczego się porządnie nie nauczysz.
>>
>> Są w internecie kody źródłowe projektów, które się udały
>> i utrzymały się przez wiele lat. Można oglądać i próbować
>> naśladować.
>
> Można. Tylko że w ten sposób niczego się porządnie nie nauczysz. To
> tak jakbyś chciał nauczyć się budowy mostów oglądając wszystkie mosty
> w zasięgu spaceru i eksperymentując z przerzucaniem kładki nad
> strumykiem.

Dla mnie "porządnie" oznacza, że umiem osiągnąć określony cel. I tę
umiejętność w dziedzinie programowania w jakimś tam stopniu nabyłem. Nie
wiem dlaczego miałbym się uczyć, jak osiągnąć ten sam cel przy pomocy
dłuższej, mniej czytelnej, ale za to obiektowej struktury programu.

do góry

Michal Kleczek wrote:

> Tak swoja droga nie slyszalem o LT krytykujacym OO - raczej krytykujacym
> C++ jako nie nadajacym sie do programowania kernela (wrecz chodzi mi po
> glowie jakies jego zdanie ze OO mozna robic w C i dlatego uzywamy C).

Ja pamiętam kojarzę jeden, gdzie też było wspomniane o OO:
http://lwn.net/Articles/249460/

a w nim fragment:

"- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap."

>> Zdecydowanie chciałbym kiedyś osiągnąć taki poziom jak L.T. a nie jak 99%
>> "profesjonalistów", mających pojęcie o "dobrych praktykach".
>
> Chcialem tylko niesmiale zaznaczyc, ze odwolywanie sie do autorytetu
> (nawet jesli Linus moze byc za taki uznany) jest slabym argumentem w
> dyskusji.

Nawet jeśli nie jest to argument w dyskusji, warto pokazać ludzi, którzy nie
ulegli modzie i odnieśli sukces.

do góry

On Apr 14, 9:13 pm, Michal Kleczek <k...@g...com> wrote:

> Nie znam sie na metodach formalnych, ale wydawalo mi sie, ze stosowanie ich
> ma zapobiegac pojawianiu sie bledow zarowno w implementacji jak i
> _specyfikacji wymagan_ .

Nie. Metody formalne mają za zadanie zapewnić, że implementacja jest
zgodna ze specyfikacją. Mogą też znaleźć sprzeczność oraz
niekompletność w specyfikacji, jeśli takie są.

Ale żadne metody formalne nie zagwarantują, że specyfikacja poprawnie
odzwierciedla to, co należało zrobić - bo zawsze można zrobić
specyfikację i "poprawną" implementację do złego problemu. To jest
ostatnie ludzkie ogniwo, które jeśli zostanie wyeliminowane, to
wszyscy pójdziemy na szczaw.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

Wojciech Jaczewski wrote:

> Michal Kleczek wrote:
>
>> Tak swoja droga nie slyszalem o LT krytykujacym OO - raczej krytykujacym
>> C++ jako nie nadajacym sie do programowania kernela (wrecz chodzi mi po
>> glowie jakies jego zdanie ze OO mozna robic w C i dlatego uzywamy C).
>
> Ja pamiętam kojarzę jeden, gdzie też było wspomniane o OO:
> http://lwn.net/Articles/249460/
>
> a w nim fragment:
>
> "- inefficient abstracted programming models where two years down the road
> you notice that some abstraction wasn't very efficient, but now all
> your code depends on all the nice object models around it, and you
> cannot fix it without rewriting your app.
>
> In other words, the only way to do good, efficient, and system-level and
> portable C++ ends up to limit yourself to all the things that are
> basically available in C. And limiting your project to C means that people
> don't screw that up, and also means that you get a lot of programmers that
> do actually understand low-level issues and don't screw things up with any
> idiotic "object model" crap."

Innymi slowy - jak sie zle zaprojektuje (inefficient abstraction), to bedzie
trudne w utrzymaniu. A uzycie C zapobiega zlemu projektowaniu.
Rozumiem ze "struct inode" i "struct inode_operations" to sa "dobre
abstrakcje" i wlasnie dlatego sa dobre, ze sa w C.
Mialem lepsze zdanie o Linusie...

>
>>> Zdecydowanie chciałbym kiedyś osiągnąć taki poziom jak L.T. a nie jak
>>> 99% "profesjonalistów", mających pojęcie o "dobrych praktykach".
>>
>> Chcialem tylko niesmiale zaznaczyc, ze odwolywanie sie do autorytetu
>> (nawet jesli Linus moze byc za taki uznany) jest slabym argumentem w
>> dyskusji.
>
> Nawet jeśli nie jest to argument w dyskusji, warto pokazać ludzi, którzy
> nie ulegli modzie i odnieśli sukces.

Nie bardzo rozumiem dlaczego uwazasz uzywanie OO za "mode". To, ze ty nie
lubisz i ze Linus nie lubi ( na razie jeszcze nie wiemy czy przypadkiem to
nie wynika z tego, ze obydwaj _nie umiecie_ ), to nie znaczy ze OO jest
tylko "moda" - jest naprawde cala masa swietnego oprogramowania OO.
Warto byloby byc bardziej otwartym na to, co robia inni i nabrac dystansu do
tego co robi sie samemu.

--
Michal

do góry

> >>> nie mam czasu ani checi na zapoznawanie sie kernelem linuksa - skoro
> >>> wiesz o czym mowisz to moze opowiesz jak to programisci c dziargaja "o
> >>> o" w linux
> >> Uchwyt pliku, id procesu, socket....
> >> Pozdrawiam
> >
> > Z tego co ja dotychczas widziałem, wielu miłośników programowania
> > obiektowego nie lubi korzystać bezpośrednio z deskryptora pliku, uważając
> > to za zbyt "niskopoziomowe" i koniecznie trzeba opakować to w jakiś
> > obiekt- zaciemniacz intencji programisty.
>
> Wszystko sie zgadza, tylko jest dokladnie odwrotnie - gdyby API do systemu
> bylo zrobione w jakims porzadnym obiektowym jezyku programowania, zaden
> "deskryptor pliku" zaciemniajacy intencje programisty nie bylby potrzebny.
> On jest potrzebny _wlasnie_ dlatego, ze koncepcje obiektowe implementuj sie
> w jezyku, ktory OO nie wspiera.
>

uchwyty do resourcow i caly ten stuff z tym, to raczej nie jest OOP :-O

wogle zapomnialem ze mozna jedno z drugim mieszac, choc teraz przypomina mi
sie ze kiedys kilka lat temu o ile pamiatam czytalem cos w czym autor troche
zbaczal w tym kierunku

w sumie jest to jednak ciekawa mysl by pomyslec o ew paralelach i o tych
uchwytach w osobnosci


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry