Maciej Sobczak wrote:

> 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,

Wiec zataczajac kolo w dyskusji - czy nie jest przypadkiem tak, ze OO - w
zamysle - ma byc narzedziem pozwalajacym wlasnie to "przejscie" (pomiedzy
rzeczywistym problemem i implementacja jego rozwiazania) uczynic latwiejszym
poprzez:
1) opis problemu odpowiadajacy jak najblizej postrzeganiu go przez ludzi (po
to zeby byl latwiej weryfikowalny)
2) implementacja jak najbardziej zblizona do opisu problemu (dzieki czemu
jest latwiej weryfikowalna i - co rownie wazne - ewentualne zmiany w
problemie daja sie w prostszy sposob przelozyc na zmiany w implementacji)

Inna sprawa to na ile ten zamysl sie daje realizowac...

> które jeśli zostanie wyeliminowane, to
> wszyscy pójdziemy na szczaw.

Ale odprawe wezmiemy :)

--
Michal

do góry

On Thu, 14 Apr 2011 22:02:49 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:

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


"Moda" jest wtedy jak sie uzywa OO "na sile". Istnieje wielka ilosc
aplikacji ktorych zrobienie w OO jest o wiele rzedow wielkosci
latwiejsze niz bez OO. Jest rownie wiele aplikacji zrobionych przy
pomocy OO gdzie OO niczego nei wnosi a wrecz zaciemnia

A.L.

do góry

Mariusz Marszałkowski wrote:

> Jaki masz wspolczynnik trafnych przwidywan do nietrawnych, co do tego,
> czy modul albo program sie rozrosnie i dobre praktyki (przerost formy
> nad
> tresica) przyspiesza jego realizacje, czy może skończy się na X<=500
> linii kodu? Ja ostatnio mam... bliski zerowego :)

Nie staram się przewidywać, czy się rozrośnie czy nie. Bez obiektowego
przerostu formy nad treścią nie muszę się tym aż tak martwić, bo nie
ograniczam się już na samym początku sztywną strukturą. I podchodzę to
projektu przyjmując założenie, że ma robić tylko to, co jest w wymaganiach w
tej chwili. Wiem, że prawie zawsze w jakimś tam stopniu się rozrośnie po
pierwszych doświadczeniach serwisowych, ale zazwyczaj nie potrafię
przewidzieć w którą stronę się to rozwinie.

do góry

On Thu, 14 Apr 2011 22:26:45 +0200, Michal Kleczek <k...@g...com>
wrote:

>
>Wiec zataczajac kolo w dyskusji - czy nie jest przypadkiem tak, ze OO - w
>zamysle - ma byc narzedziem pozwalajacym wlasnie to "przejscie" (pomiedzy
>rzeczywistym problemem i implementacja jego rozwiazania) uczynic latwiejszym
>poprzez:

Nie. OO w niczym nie pomoze w ustaleniu co software ma robic, i czy to
co wyartykulowano co ma robic jest prawidlowe.

A.L.

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...

>

Na pewno go to wielce obchodzi 'Wspanialy Mistrzu' (kojarzacy mi sie
nieodmiennie z pijanym zolnierzem komentujacym wobec kamratow wyobrazane
decyzje dowodztwa, po czym sikajacym w krzakach do momentu nim Thorgal
albo ktos taki nie zdzieli go pala w drodze do wystrzelenia liki
z zaczepem by wspiac sie na mury)

To wszystko doskonale potwierdza moje spostrzezenie ze klonerzy ('oo')
to zoldacy imperium


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

do góry

Michal Kleczek wrote:

>> "- 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.

Użycie C sprawia, że pomimo złego zaprojektowania, daje się to później
skorygować bez przepisania od nowa całości.
A projektuje się źle dlatego, że nie da się wszystkiego przewidzieć przed
rzeczywistą próbą wykonania projektu.

> Nie bardzo rozumiem dlaczego uwazasz uzywanie OO za "mode".

Choćby z tego powodu, że większość ludzi tuż po studiach, bez większego
doświadczenia, bardzo je chwali. U ludzi z doświadczeniem, ta ocena jest
bardziej zróżnicowana. Cóż więc innego niż moda sprawia, że ludzie bez
doświadczenia w to wierzą?

> 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.

Załóżmy, że technikę A stosuje 80% osób (bo ktoś zainspirowany modą im
nakazał) i tworzy się z jej użyciem dwukrotnie wolniej niż korzystając z
techniki B, którą to używa pozostałe 20% osób. W której technice powstanie
więcej programów?

> Warto byloby byc bardziej otwartym na to, co robia inni i nabrac dystansu
> do tego co robi sie samemu.

Jak dla mnie dyskusja na grupie nie służy demonstrowaniu dystansu do tego co
się robi, tylko prezentowaniu wypowiedzi zdecydowanych... Ja osobiście nie
lubię dyskusji z osobami, które są tak otwarte na to co robią inni, że nie
da się poznać ich własnej opinii.

do góry

On Thu, 14 Apr 2011 23:41:10 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:

>Michal Kleczek wrote:
>
>>> "- 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.
>
>Użycie C sprawia, że pomimo złego zaprojektowania, daje się to później
>skorygować bez przepisania od nowa całości.


W OO tez sie da. Proponuje poczytac o "refactoring"

A.L.

do góry

Dnia 14.04.2011 Wojciech Jaczewski <w...@o...pl> napisał/a:

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

Jeszcze Joe Armstrong, w wywiadzie z Peterem Seibelem w "Coders at Work":

I think the lack of reusability comes in object-oriented languages,
not in functional languages. Because the problem with object-oriented
languages is they've got all the implicit environment that they carry
around with them. You wanted a banana but what you got was a gorilla
holding the banana and the entire jungle.

If you have referentially transparent code, if you have pure functions--
all the data comes in its input arguments and everything goes out and
leaves no state behind--it's incredibly reusable.

pozdrawiam,
Daniel

do góry

On Thu, 14 Apr 2011 22:22:12 +0000 (UTC), Daniel Janus
<n...@d...pl> wrote:

>Dnia 14.04.2011 Wojciech Jaczewski <w...@o...pl> napisał/a:
>
>> Nawet jeśli nie jest to argument w dyskusji, warto pokazać ludzi, którzy nie
>> ulegli modzie i odnieśli sukces.
>
>Jeszcze Joe Armstrong, w wywiadzie z Peterem Seibelem w "Coders at Work":
>
> I think the lack of reusability comes in object-oriented languages,
> not in functional languages. Because the problem with object-oriented
> languages is they've got all the implicit environment that they carry
> around with them. You wanted a banana but what you got was a gorilla
> holding the banana and the entire jungle.
>
> If you have referentially transparent code, if you have pure functions--
> all the data comes in its input arguments and everything goes out and
> leaves no state behind--it's incredibly reusable.
>
>pozdrawiam,
>Daniel

Kompletny belkot. Tacy sa wlasnie "gurus".

A.L.

do góry

On 14 Kwi, 21:41, Michal Kleczek <k...@g...com> wrote:
> 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.
>

Istotnym i naprawde czasochlonnym problemem sa bledy na poziomie
projektu.
Gdy one sie pojawiaja, trzeba wracac do rzeczy dawno napisanych,
wszystko
zmieniac, albo zacmienic kod gaszczem ifow. Duzy narzut jest takze w
sytuacji
gdy sie nie uzywa gotowych bibliotek, a klepie samemu od poczatku.
Natomiast
narzut spowodowany uzyciem jezyka niewspierajacego (bezposrednio)
obiektowosci
jest minimalny. Dobry projekt z dobrym bibliotekami zostanie ukonczony
10
razy szybciej niz kiepski bez bibliotek ale w jezyku wspomagajacym
obiektowosc.

Pozdrawiam

do góry