Użytkownik "Edek Pienkowski" <e...@g...com> napisał:

>>> Niektórzy uważają OOP za chwast.
>>
>> Glupcow nie sieja :(.
>> Pytam sie. Co w zamian ?
>> Co w lepszym stopniu modeluje Pania Rzeczywistosc ?
>
> To dlaczego obiekty nie są do pary? Dlaczego nie ma
> podstawowej formy [obiekt] -> [obiekt] [za pomocą [obiekt]]?
> Dlaczego nie ma formy nie tyle płynnej co złożonej
> z mniejszych obiektów, jak żużel?

Wpadles w pulapke.
To nie sa argumenty PRZECIW OOP.
To co piszesz to przeciez _wciaz_ jest OOP tyle ze
(w/g Ciebie oczywiscie bo sprawa jest dyskusyjna bardzo)
to sa rzeczy ew. brakujace OOP a nie mu przeczace.
To sa ew. argumenty za OOP i jego ROZWOJEM OOP
a nie jego zaniechaniem.

> Całe to modelowanie rzeczywistości, jakaś inna ta rzeczywistość
> od mojej, a krok dalej jest UML, tu już czasami świta we łbie
> że z Panią Rzeczywistością to już niewiele ma wspólnego. Dalej
> jest tylko ZUS :)

Nie znam UMLa, a pol zycia pisze w OOP.
UML to tylko jedna z _notacji_, a nie OOP.

> Ktoś mi tu wyciął jedyne sensowne zdanie cytując ;)

Nie rozumiem ? Nie mam w zwyczaju zostawiac calej notki
dipisujac jedno zdanie zdanie. Wycinam wiec.
Zostawiam to do czego sie odnosze, a wiec precyzujac:
Nie rozumiem tych osob

PS: Pytam po raz wtory.
_Co_ (jaki paradygmat) lepiej dzis modeluje Pania Rzeczywistosc niz OOP ? Hę ?

AK

do góry

Dnia Tue, 24 Jul 2012 23:33:34 +0200, AK napisal:

> Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
>
>>>> Niektórzy uważają OOP za chwast.
>>>
>>> Glupcow nie sieja :(.
>>> Pytam sie. Co w zamian ?
>>> Co w lepszym stopniu modeluje Pania Rzeczywistosc ?
>>
>> To dlaczego obiekty nie są do pary? Dlaczego nie ma
>> podstawowej formy [obiekt] -> [obiekt] [za pomocą [obiekt]]?
>> Dlaczego nie ma formy nie tyle płynnej co złożonej
>> z mniejszych obiektów, jak żużel?
>
> Wpadles w pulapke.
> To nie sa argumenty PRZECIW OOP.
> To co piszesz to przeciez _wciaz_ jest OOP tyle ze
> (w/g Ciebie oczywiscie bo sprawa jest dyskusyjna bardzo)
> to sa rzeczy ew. brakujace OOP a nie mu przeczace.
> To sa ew. argumenty za OOP i jego ROZWOJEM OOP
> a nie jego zaniechaniem.

Przeciw nie, ale tak by po ludzku wyglądało modelowanie
rzeczywistości, a nie 1000 obiektów klasy Komar.

Z tym rozwojem OO w tym kierunku... fir może się wypowie
konkretniej na ten temat.

>> Całe to modelowanie rzeczywistości, jakaś inna ta rzeczywistość
>> od mojej, a krok dalej jest UML, tu już czasami świta we łbie
>> że z Panią Rzeczywistością to już niewiele ma wspólnego. Dalej
>> jest tylko ZUS :)
>
> Nie znam UMLa, a pol zycia pisze w OOP.
> UML to tylko jedna z _notacji_, a nie OOP.
>
>> Ktoś mi tu wyciął jedyne sensowne zdanie cytując ;)
>
> Nie rozumiem ? Nie mam w zwyczaju zostawiac calej notki
> dipisujac jedno zdanie zdanie. Wycinam wiec.
> Zostawiam to do czego sie odnosze, a wiec precyzujac:
> Nie rozumiem tych osob

No to mamy ucieleśnienie fanatyzmu OOP.

>
> PS: Pytam po raz wtory.
> _Co_ (jaki paradygmat) lepiej dzis modeluje Pania Rzeczywistosc niz
> OOP ? Hę ?

No właśnie nie ma takich, bo chwast OOP sformatował wszystkich skutecznie.
Taka spiskowa teoria na temat much co się nigdy nie mylą. Albo Komarów.

Edek

do góry

On 24/07/2012 21:48, AK wrote:
> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:
>
>> No to albo ja mam skrajnie nietypowe doświadczenia, albo nie jest to
>> prawdą.
>
> Po prostu malo jest takich zespolow, bo.. brakuje dobrych ludzi/sa drodzy.
> Programowanie (i rynek) juz dawno zwyczajnie spsialo (pod kazdym wzgledem).
> PS: Mowie glownie o Polsce. Na "zagranicy" srednio "sie znam".

W Polsce też różnie zdaje się bywa, ale jakiegoś szczególnie wielkiego
doświadczenia nie mam. W ogóle oczywiście to często zależy od rodzaju i
wielkości instytucji: tam, gdzie oprogramowanie tworzy, jak to pisze
Roman, "dział IT", a biznesem firmy jest co innego, to być może jest
tak, że kierownictwo się za bardzo nie wtranżala programistom w to, jak
mają pracować. Ja z kolei mam raczej doświadczenie z firmami, w których
"dział IT" jest od zakładania (między innymi) programistom kont na
domenie i tym podobnych, a biznees firmy polega na produkcji
oprogramowania, często jednocześnie wielu różnych programów tworzonych
przez różne zespoły. Zwłaszcza w większych firmach taka konfiguracja
jest podatna na różne dziwne pomysły kierownictwa średniego szczebla na
np. "ujednolicone procesy", których celem jest przypuszczam na ogół
ułatwienie wygenerowania ładnych raportów i wykresów, które stwarzają
pozór przekazywania jakichś istotnych informacji na temat całokształtu
działań firmy.

Małe zespoły w małych firmach, zwłaszcza złożone z bardziej
doświadczonych ludzi, mogą częściej organizować się same, ale w takich
przypadkach łatwiej o pułapkę "cowboy coding". I chociaż akurat
teoretycznie doświadczenie i wiedza mogą temu zapobiegać, to jednak ten
syndrom został wykryty na bardzo doświadczonych koderach. Można mieć
ogromną wiedzę, doświadczenie i praktyczną umiejętność wytwarzania
działających programów, ale nadal być "cowboy coder", wystarczy, że się
albo nie zna, albo z założenia nie uznaje jako "nowomodne fanaberie"
różnych co nowszych (lub po prostu relatywnie niedawno
spopularyzowanych) osiągnięć inżynierii oprogramowania (i tak, OOP/OOD
też się do tego zalicza), na zasadzie "my ze szwagrem po pijaku nie
takie rzeczy na GOTO stawialiśmy".

Osobną sprawą jest kwestia zewnętrznych warunków powstawania takiego
oprogramowania, czyli raportowania, estymowania i inputu. Pewnym ideałem
jest, kiedy wymagania są od początku znane i rozumiane i można po prostu
wziąć dobry zespół i kazać im to zrobić, wiedząc że skoro są dobrzy i
sumienni, to i tak zrobią to szybciej i lepiej niż przypadkowy inny
zespół. Rzeczywistość niestety jest bardziej skomplikowana: są klienci,
którzy nie zawsze i nie do końca wiedzą, czego chcą, ale jedno co
wiedzą, to że potrzebują tego na wczoraj, dziedzina jest skomplikowana,
klient robi wiele rzeczy po swojemu, a w ogóle to chciałby robić jeszcze
inaczej (chociaż do końca nie wie jak), tylko nie ma odpowiedniego
oprogramowania, i po to właśnie przyszedł do ciebie; co gorsza jeszcze
takich klientów może być kilku, ich żądania będą miały różne priorytety,
dział sprzedaży będzie chciał wiedzieć, na kiedy co będzie zrobione,
kierownictwo będzie chciało wiedzieć jaki jest stan prac, a developerzy
będą chcieli wiedzieć, co właściwie mają robić i jak właściwie ma to
działać.

W zależności jak to wszystko jest zorganizowane, możesz mieć z łatwością
sytuację, kiedy zespół złożony z dobrych ludzi jest dysfunkcjonalny. Na
ten przykład (true story) developer, kiedy widzi, że feature request
jest co prawda niezbyt skomplikowany, ale za to prawdopodobnie
bezsensowny, i domyśla się, że temu, kto go napisał wydawało się, że
dzięki takiemu ficzerowi cośtam osiągnie, czego w rzeczywistości raczej
nie osiągnie, zamiast chrzanić się, biegać od Annasza do Kajfasza,
tłumaczyć, dopytywać i ściągać na siebie gniew, machnie na to ręką i
powie "zrobię to tak, jak napisali, chociaż to bez sensu, jak się okaże,
że nie da się tego używać, to będzie to problem kogoś innego".

do góry

On 24/07/2012 21:46, AK wrote:
> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:
>
>> Sarkazm?
>
> Jaki sarkazm ? Rzeczywistosc.

No więc nie wiem, czy sobie zdajesz z tego sprawę, ale swoimi
wypowiedziamy bardziej szkodzisz niż pomagasz sprawie, której bronisz.

> Masz dwie nogi (zawieranie, atrybuty),
> jestes szczegolym przypadkiem Homo Erectus (polimorfizm) ?

Nigdy nie byłem mocny z paleontologii, ale mam nadzieję, że jednak nie.
Choćby dlatego, że bym już nie żył co najmniej od jakiegoś miliona lat.

> Raczej chyba nie jestes zbiorem funkcji bez efektow ubocznych
> (no chyba ze abstynent:) i z lazy ewaluation ?

Ewaluation jak najbardziej lazy, ponadto żadne metody na mnie nie
działają, a co więcej nie mam żadnych pól prywatnych, bo nie jestem
rolnikiem.

do góry

On 24/07/2012 21:40, AK wrote:
> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:
>
>>> TDD ?
>>> A to aby czasem nie zwykle stare dobre (od zawsze znane) testy
>>> integracyjne ?
>> Nie.
>
> Jak nie jak tak :)

Już ze zdumieniem się dowiedziałem, że według ciebie agile zaleca jakieś
głosowania w zespole czy coś w tym stylu. Bardzo bym był ciekaw się
dowiedzieć, na czym według ciebie polega TDD.

Bo to TDD, które ja znam, to nie są żadne "testy".

do góry

On 24/07/2012 21:39, AK wrote:
> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:
>
>> Jak ci zabierają wypłatę, to agile nic ci nie da.
>
> No fakt, tylko że.. nic nie zrozumiałeś.
> Nikt mi wypłaty nie zabiera.
> Sam ją JEJ grzecznie oddaję.
> Jeno mam poźniej problem z odzyskiwaniem (nawet na słonecznik czy dropsy :(

Ach, musisz wykazać się zrozumieniem, jako że rozmawiasz z Tą Dzisiejszą
Młodzieżą. Mnie po prostu przelewają na konto.

do góry

AK wrote:

>> Niektórzy uważają OOP za chwast.
>
> Glupcow nie sieja :(.
> Pytam sie. Co w zamian ?
> Co w lepszym stopniu modeluje Pania Rzeczywistosc ?

Pomijając szczegół, czy OOP modeluje rzeczywistość, czy jej nie modeluje, to
modelowanie rzeczywistości jest celem jedynie pewnej grupy programów, moim
zdaniem stosunkowo wąskiej.
Większość tworzonego oprogramowania spełnia inne cele niż modelowanie
rzeczywistości.

Ktoś się wysilił i napisał dłuższy tekst na temat modelowania rzeczywistości
przez OOP: http://www.geocities.com/tablizer/model.htm

do góry

On Tuesday, July 24, 2012 9:23:42 PM UTC+1, Andrzej Jarzabek wrote:
> On 24/07/2012 20:08, Roman W wrote:
> &gt; On Tuesday, July 24, 2012 7:55:42 PM UTC+1, Andrzej Jarzabek wrote:
> &gt;&gt;
> &gt;&gt; To tak samo jak, powiedzmy, OOP. I przeciee� te� mo�esz przeczyta�
takie
> &gt;&gt; opinie ludzi z crowdu od &amp;quot;C/COBOL/Fortran to najlepszy j�zyk
evah&amp;quot;. A to
> &gt;&gt; oczywi�cie te� s� religie.
> &gt;
> &gt; No nie. OOP jest znacznie scislej okreslone niz Agile.
>
> Katolicyzm również.
>
> Natomiast czy potrafisz wymienić coś takiego, bez czego nie ma OOP

Chocby enkapsulacja.

>, albo
> co powoduje, że jest się OO?

Jezeli masz enkapsulacje, abstrakcyjne interfejsy, kod stowarzyszony z danymi oraz
"stary kod moze wywolywac nowy kod", to IMHO mozesz juz mowic o OOP.

OK, moge pewnie powiedziec, ze nie ma Agile bez Scrum albo ze jak mam Scrum to mam
Agile. Tylko ze roznica jest, ze w przypadku OOP te "must have features" to sa
uzyteczne rzeczy same w sobie, natomiast Scrum to rytual. Uzyteczne rzeczy sa
przemycane obok (jak TDD). No to ja sie pytam, czy musze miec rytual zeby robic TDD -
nie musze.

RW

do góry

On 25/07/2012 07:18, Roman W wrote:
> On Tuesday, July 24, 2012 9:23:42 PM UTC+1, Andrzej Jarzabek wrote:
>>
>> Natomiast czy potrafisz wymienić coś takiego, bez czego nie ma OOP
>
> Chocby enkapsulacja.

To dość niejednoznaczne pojęcie, ale kolesie od Lispa i innego
programowania funkcyjnego powiedzą ci, że robili enkapsulację na długo
przed OO i dalej robią bez żadnego OO.

Z kolei aspekty enkapsulacji, zarówno wiązanie kodu z danymi, jak i
ukrywanie prywatnych danych i prywatnego kodu, było robione w typowo
stukturalno/proceduralnym programowaniu przez użycie modułów.

A taki Python jest uważany za język wspierający OO, a nie pozwala na
information hiding.

>> , albo
>> co powoduje, że jest się OO?
>
> Jezeli masz enkapsulacje, abstrakcyjne interfejsy, kod stowarzyszony z danymi oraz
"stary kod moze wywolywac nowy kod", to IMHO mozesz juz mowic o OOP.

Wydaje mi się, że jeśli weźmiesz ogół rozwiązań (języków, innych
narzędzi) i konkretnych programów, które można określić i są określane
jako OO, to często będzie brakować przynajmniej jednej z tych rzeczy,
albo ich obecność będzie sporna. Każda z tych rzeczy może też występować
w rozwiązaniach zdecydowanie nie będących OO, zapewne mogłyby również
wszystkie na raz.

> OK, moge pewnie powiedziec, ze nie ma Agile bez Scrum albo ze jak mam Scrum to mam
Agile. Tylko ze roznica jest, ze w przypadku OOP te "must have features" to sa
uzyteczne rzeczy same w sobie, natomiast Scrum to rytual. Uzyteczne rzeczy sa
przemycane obok (jak TDD). No to ja sie pytam, czy musze miec rytual zeby robic TDD -
nie musze.

Na pewno nie można powiedzieć, że nie ma agile bez Scrum; są różne
metodologie agile, Scrum jest tylko jedną z nich.

Scrum jako takie jest dość nieźle zdefiniowane, teoretycznie można są
konkretne rzeczy, o których można powiedzieć, że jak je robisz, to
robisz Scrum, a zatem jesteś Agile. Problem jest taki, że Scrum ma
aspekt, nazwijmy to, rytualistyczny, i jego wykonywanie jest
najłatwiejsze do sprawdzenia, ale podstawą są w nim pewne zasady, z
których wynika _po co_ są te wszystkie rytuały, i właśnie w aspekcie
tych zasad i celu robienia tego wszystkiego Scrum jest agile, a nie w
aspekcie konkretnych rytuałów. Tak więc jeśli masz codzienne zebrania,
które nazywasz "scrum", jeśli używasz do estymacji kart ze "story
points", jeśli nazwiesz team leada "scrum master" i jeśli robisz inne
zebrania w dwutygodniowych cyklach, które nazywasz "sprintami", to nie
czyni cię to ani trochę bardziej "agile". Inne kwestie są trochę
trudniejsze do "odhaczenia". Skąd wiesz, że praktykujesz "openness"? W
niektórych firmach robi się tak, że każdy pracownik dostaje list od CEO,
że w naradzie z senior managerami zdecydowali, że ma być openness i od
tej pory wszyscy pracownicy są zachęcani żeby praktykować openness.
Podobnie jest z takimi sprawami jak autonomia zespołu.

Wydaje mi się, że na ogół problemy z adopcją agile polegają na tym, że
czyta się o scrumie, ignoruje się lub wypiera wszystko, czego zrobienie
w danych warunkach byłoby trudne, i wynosi się z tego, że jak się będzie
robić codzienne "scrumy", dwutygodniowe "sprinty", burndown charty i co
tam jeszcze, to będzie lepiej. I potem zdziwienie.

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał:

>> Wpadles w pulapke.
>> To nie sa argumenty PRZECIW OOP.
>> To co piszesz to przeciez _wciaz_ jest OOP tyle ze
>> (w/g Ciebie oczywiscie bo sprawa jest dyskusyjna bardzo)
>> to sa rzeczy ew. brakujace OOP a nie mu przeczace.
>> To sa ew. argumenty za OOP i jego ROZWOJEM OOP
>> a nie jego zaniechaniem.
>
> Przeciw nie, ale tak by po ludzku wyglądało modelowanie
> rzeczywistości, a nie 1000 obiektów klasy Komar.

Wez sobie polacz OOP z GOP Icona (albo Pythona) +
napisz sobie odpowiednia metode/operator indeksujacy
(w Py __getitem__) i mozesz sobie dowolnie "modelowac"
te 1000 komarow. IMHO argument wydumany bo nie tyczy
wcale OOP ale kontenerow/generatorow.

> Z tym rozwojem OO w tym kierunku... fir może się wypowie
> konkretniej na ten temat.

Fir nie jest talki glupi jakiego udaje. Fir ma po prostu problem.

>> Nie rozumiem tych osob
>
> No to mamy ucieleśnienie fanatyzmu OOP.

Edziu, ja z Toba probuje dyskutowac a Ty po prostu mlody i "guuuupi" jestes ;).

>> PS: Pytam po raz wtory.
>> _Co_ (jaki paradygmat) lepiej dzis modeluje Pania Rzeczywistosc niz
>> OOP ? Hę ?
>
> No właśnie nie ma takich, bo chwast OOP sformatował wszystkich skutecznie.

J/w. Ale ok. Beknij chociaż zarysem jakiejkolwiek powaznej alternatywy.

> Taka spiskowa teoria na temat much co się nigdy nie mylą. Albo Komarów.

J/w.

AK

do góry