W dniu 2011-04-14 22:17, p...@p...onet.pl pisze:

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


JEST

(inny etap, inny jezyk), ale to jest w bezposredniej linii prowadzacej
do OOP. Te wszystkie Control Bloki, wskazniki na funkcje, szersze wersje
bloku i wezsze itd. Dziedziczenie, klasa a obiekt, metody jako takie,
metody wirtulne, to wszystko tam juz jest.
To wszystko (poznanie zalet i wad) zaowocowalo OOP. Jezyk obiektowy to
lepiej obudowal (np. nie bylo wczesniej dobrego 'private' - byly tylko
konwencje, oraz gwarantowanej poprawnej inicjacji)

Wypowiadasz sie o smaku szpinaku którego nie jadles.

do góry

W dniu 2011-04-14 23:41, Wojciech Jaczewski pisze:

> 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ą?
>

Wiesz co, ja na studiach (informatyka) nie mialem OOP.
Np bylo C z konwencjami nazewniczymi, a proj. nie tylko studenckie,
rowniez udzial w projektach Instytutu itd.

OOP uczylem sie w trakcje sciezki zawodowej.

Pierwsze biblioteki OOP (Turbo Vision, OVL i kilka innych) byly
skrzywione, przesadna glebokosc dziedziczenia zamiast wzorcow
projektowych itd, to bylo trudne. Rowniez chyba takie 'dziedziczenie'
bylo w dydaktyce.
Jednak 'druga fala' jest ok.

uwazam ze OOP to bardzo dobra odpowiedz na NASZE stare potrzeby
przemyslowych programistow w zakresie nazewnictwa, wyrazania intencji,
izolacji interfejsu od implementacji itd. Oraz ochrony przed glupimi
bledami (zapomnienie zainicjowania itd, znane sprawy).

do góry

W dniu 2011-04-14 23:50, A.L. pisze:

>> 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"
Co wiecej, w OOP refaktoring jest jakby czytelniejszy, pewniejszy,
bezpieczniejszy - ze wzgledu na formalizm type-safe dobrych jezykow,
oraz na poziomie ludzkim zwykle kod OO bardziej plastycznie oddaje
intencje 'co wlasciwie ja tutaj pól roku temu chcialem zrobic ???'

Nie mowie o eleganckich teoretycznych projektach, ale o 'panszczyznie'
przemyslowej, zawsze spoznionej, zawsze za slabo udokouumentowanej itd.
Im jest gorzej, tym bardziej sie to przydaje.

do góry

Wojciech Jaczewski wrote:

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

Jasne - i poniewaz jest to wszystko takie dobre, to praktycznie kazda nowa
wersja jadra wymaga patchy do zewnetrznych modulow, zeby sie je dalo
skompilowac. Jak ktos uzywa VMWare na Linuksie to wie o czym mowie.

Juz nawet nie wspominam o tym, ze w ogole jakas tam rekompilacja powinna byc
niepotrzebna - ale to inna sprawa.

>> 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ł)

A kto niby nakazal stosowac OO?

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

Szybkosc tworzenia systemu _nie_ jest jedynym kryterium oceny. Rownie wazne,
a czesto wazniejsze jest by:
1) bylo mniej bledow
2) system byl latwiejszy w modyfikiacji/rozbudowie

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

To zalezy, jaki sobie stawiasz cel w dyskusji. Czy jest to przekonanie
innych do wlasnego zdania, czy tez poszerzenie wlasnych horyzontow poprzez
wymiane pogladow.

--
Michal

do góry

Mariusz Marszałkowski wrote:

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

Oczywiscie. Tyle, ze wybor jezyka(ow) programowania i paradygmatu(ow)
tworzenia oprogramowania sa jednymi z wazniejszych decyzji projektowych
jakie trzeba podjac. Te decyzje sa ze soba powiazane i decyzja o stosowaniu
jezyka nie wspierajacego wybranego paradygmatu powinna byc baaaardzo dobrze
umotywowana innymi czynnikami (typu np. brak ludzi znajacych dany jezyk,
brak kompilatora/narzedzi, brak bibliotek itp.)

Swoja droga brak ludzi znajacych jakis jezyk jest bardzo dobrym argumentem
przeciwko temu jezykowi. Ale warto byc tutaj uczciwym i postawic sprawe
jasno, a nie (falszywie) motywowac swoja decyzje tym, ze jezyk A jest
"gorszy".

--
Michal

do góry

W dniu 2011-04-14 23:41, Wojciech Jaczewski pisze:
> 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.

Z mojej praktyki - błędy projektu w C były zazwyczaj obchodzone
dodatkowym "sznurkiem i taśmą klejącą" w postaci niekontrolowanych
wywołań między modułami, ze szczególnym upodobaniem do odwołań do
zmiennych globalnych i funkcji z założenia prywatnych dla modułu.

W C++ - tworzeniem i rozbudowywaniem "The Class", co dawało taki sam
efekt.

Mój wniosek - zabagnienie w C jest nieco łatwiej rozwikłać niż w C++.
Za to łatwiej unikać zabagnienia w C++ niż w C, bo C++ (szczególnie
jeśli na początku dobrze użyte) narzuca pewne ograniczenia. W końcu
trzeba jakoś wytłumaczyć, czemu "friend" i "public".

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

Dla mnie nie jest argumentem opinia innych. Staram się wyrabiać własną
opinię na podstawie argumentów innych.

--
Paweł Kierski
n...@p...net

do góry

On Apr 15, 12:22 am, Daniel Janus <n...@d...pl> wrote:

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

WTF? Jaki implicit environment?
Wszystkie znane mi języki wspierające OO potrzebują jedynie bibliotekę
run-time - nie różnią się w tym od innych języków. Co prawda języki
typu zer-runtime istnieją, ale funkcjonalne do nich też nie należą.
Niektóre języki OO wymagają jeszcze kompilatora, ale w tym też nie
różnią się od wielu innych języków.

Nie za bardzo widzę jakiż to implicit environment jest potrzebny w OO,
który istotnie odróżniałbym te języki od funkcjonalnych. Czyli
bullshit.

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

WTF? Stan powstaje dopiero w czasie wykonania a reusability to cecha
kodu źródłowego. Jedno z drugim nie ma żadnego związku. Czyli
bullshit.

BTW - Czym się różni użycie języków OO bez zrozumienia od użycia
języków funkcjonalnych bez zrozumienia? Chyba tylko poziomem snobizmu.

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

do góry

W dniu 2011-04-15 00:22, Daniel Janus pisze:
> 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

Jak się nie umie abstrahować banana od goryla i dżungli, to żaden język
ani paradygmat nie pomoże.

Mniej anegdotycznie - dla nieumiejących zapanować nad stanem
obiektu/aplikacji/zmiennej i rozdzielać odpowiedzialności między
klasami, paradygmat funkcyjny będzie prostszy.

--
Paweł Kierski
n...@p...net

do góry

On Apr 15, 9:07 am, Michal Kleczek <k...@g...com> wrote:

> A kto niby nakazal stosowac OO?

Problem z OO bierze się stąd, że niektóre języki *wymuszają* jego
użycie i nawet rzeczy zupełnie nieobiektowe trzeba tak robić. W takim
języku biblioteki do czegokolwiek są obiektowe, frameworki do
czegokolwiek są obiektowe, itd. To promieniuje na boki i oddziałowuje
na całą resztę, więc potem ludzie usiłują tą logikę (lub jej brak)
stosować gdzie indziej, nawet jak nie muszą.

To nie jest kwestia mody. W Korei Północnej wszyscy ubierają się na
szaro i wielu ludzi nawet jest z tego dumnych, ale to też nie jest
kwestia spontanicznej mody, tylko efekt wtórny.

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

do góry

Maciej Sobczak wrote:

> On Apr 15, 9:07 am, Michal Kleczek <k...@g...com> wrote:
>
>> A kto niby nakazal stosowac OO?
>
> Problem z OO bierze się stąd, że niektóre języki *wymuszają* jego
> użycie i nawet rzeczy zupełnie nieobiektowe trzeba tak robić. W takim
> języku biblioteki do czegokolwiek są obiektowe, frameworki do
> czegokolwiek są obiektowe, itd. To promieniuje na boki i oddziałowuje
> na całą resztę, więc potem ludzie usiłują tą logikę (lub jej brak)
> stosować gdzie indziej, nawet jak nie muszą.

Potrzeba wieloparadygmatowosci wydaje sie dzis oczywista. I jezyki
wieloparadygmatowe (lepsze lub gorsze) istnieja.

Rozumiem te obiekcje i zgadzam sie z nimi - poniekad. Problem jest jednak
taki, ze narzedzia (czyli jezyki) sa pochodna paradygmatu. OO ma _wlasnie_
taka zalete, ze istniejace metodyki i wspierajace je narzedzia stanowia
_spojna_ calosc.
Jak pisalem w innym poscie - brak "wieloparadygmatowych metodyk" jest dzis
sporym problemem. Zas uzycie innego paradygmatu w projekcie prowadzonym
wedle metodyki do niego niedostosowanej (czyli ad-hoc) prowadzi do
nieprzewidzianych skutkow. Wydaje mi sie, ze jednak najczesciej te skutki sa
niekorzystne, wlasnie dlatego ze robione jest to ad-hoc. W kazdym razie
decyzje takie niosa ze soba _ryzyko_ co w praktyce czesto je wyklucza.
Wbrew pozorom trzymanie sie ( kurczowo/religijnie/doktrynalnie :) )
metodyki/paradygmatu - nawet znajac ich wady - ma duzy sens, szczegolnie w
przemysle ( w projektach akademickich lub hobbystycznych czy open source -
pewnie mniejszy, bo "poszukiwania" sa jednym z celow takiego projektu ).

--
Michal

do góry