On 11/04/2011 19:04, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>
>> Z drugiej strony też jest tak, że jak ktoś nie zna albo nie potrafi
>> stosować pewnych technik, to często uważa je za niepotrzebne (np. za
>> "przerost formy nad treścią", co uzadania tym, że sam potrafi się bez
>> nich obejść. I to też jest częsta przypadłość ludzi, którzy "uczyli się
>> sami".
>
> Dzięki temu, że uczyłem się sam, zdołałem się wydostać z pułapki stosowania
> właśnie takiego przerostu formy nad treścią. Bo gdy zacząłem stosować m.in.
> techniki "obiektowe", miałem możliwość porównania efektów z tym, co robiłem
> zanim zacząłem je stosować. Początkowo wydawało mi się, że to tylko
> przejściowe trudności (że skoro wszyscy to propagują, to pewnie coś w tym
> jest), ale po jakichś dwóch latach dotarło do mnie, że rzeczywiście
> zmieniłem technikę na gorszą i trzeba się z tego wycofać.

Nie wiem co stosowałeś, jak i dlaczego, ale jeśli chcesz powiedzieć, że
techniki obiektowe to taki właśnie przerost formy nad treścią, którego
uczą na uczelniach, ale w praktyce komercyjnej nie mają innego
znaczenia, to nie da się tego nazwać inaczej niż bzdurą. W
rzeczywistości większość oprogramowania komercyjnego tworzy się z
użyciem technik obiektowych i mają one kolosalne znaczenie dla
wydajności tworzenia programów i ich niezawodności. I owszem, jak ktoś
chce pracować jako programista, a nie umie porządnie stosować technik
obiketowych, to jest dla niego strata i często też strata dla tych, co
mu dadzą pracę.

do góry

Andrzej Jarzabek wrote:

>> Dzięki temu, że uczyłem się sam, zdołałem się wydostać z pułapki
>> stosowania właśnie takiego przerostu formy nad treścią. Bo gdy zacząłem
>> stosować m.in. techniki "obiektowe", miałem możliwość porównania efektów
>> z tym, co robiłem zanim zacząłem je stosować. Początkowo wydawało mi się,
>> że to tylko przejściowe trudności (że skoro wszyscy to propagują, to
>> pewnie coś w tym jest), ale po jakichś dwóch latach dotarło do mnie, że
>> rzeczywiście zmieniłem technikę na gorszą i trzeba się z tego wycofać.
>
> Nie wiem co stosowałeś, jak i dlaczego, ale jeśli chcesz powiedzieć, że
> techniki obiektowe to taki właśnie przerost formy nad treścią, którego
> uczą na uczelniach, ale w praktyce komercyjnej nie mają innego
> znaczenia, to nie da się tego nazwać inaczej niż bzdurą.

Nie twierdzę, że się ich nie stosuje, tylko że często się je stosuje
niepotrzebnie. A da się też robić dobre programy bez nich.
Oczywiście, jeśli w jakiejś firmie kierownictwo się uprze, że programy mają
być obiektowe, to inaczej nie można.
Na szczęście nie wszędzie jest taki wymóg (nie znam statystyk). U mnie na
szczęście zagadnienia dają się podzielić na osobne, działające wspólnie w
systemie procesy, więc nie trzeba prowadzić wojen o strukturę programu -
każdy wykonuje taką, jaka mu pasuje.

> W
> rzeczywistości większość oprogramowania komercyjnego tworzy się z
> użyciem technik obiektowych i mają one kolosalne znaczenie dla
> wydajności tworzenia programów i ich niezawodności.

W pozytywny wpływ technik obiektowych na niezawodność zwyczajnie nie wierzę.
Z moich obserwacji, awaryjność moich programów powstałych po odrzuceniu
większości technik obiektowych wyraźnie spadła, natomiast ogromnie poprawiła
się elastyczność - w sensie, że pojawiają się nowe wymagania i trzeba
program szybko do nich dostosować. Tworząc jakieś hierarchie obiektów,
ciągle natrafia się na coś, czego się nie przewidziało i trzeba prawie
całkowicie przebudowywać program.

> I owszem, jak ktoś
> chce pracować jako programista, a nie umie porządnie stosować technik
> obiketowych, to jest dla niego strata

A może po prostu ci miłośnicy technik obiektowych nigdy nie nauczyli się
porządnie stosować technik nie-obiektowych i to ich strata?

> i często też strata dla tych, co
> mu dadzą pracę.

Jeśli liczyli na to, że będzie pokornie programował obiektowo, to tak.
Natomiast jeśli chcą aby efekty jego programowania były dobre - już
niekoniecznie.

do góry

Tak do poprzedniej wypowiedzi jeszcze dodam, że mam mniej-więcej te same
obserwacje, co autor "The Art of Unix Programming", chociaż przeczytałem ten
tekst później, niż zacząłem praktykować elementy opisanej tam filozofii
tworzenia oprogramowania.
Rozdział na temat programowania obiektowego:
http://www.catb.org/~esr/writings/taoup/html/unix_an
d_oo.html

do góry

Dnia 12.04.2011 Wojciech Jaczewski <w...@o...pl> napisał/a:
> Tak do poprzedniej wypowiedzi jeszcze dodam, że mam mniej-więcej te same
> obserwacje, co autor "The Art of Unix Programming", chociaż przeczytałem ten
> tekst później, niż zacząłem praktykować elementy opisanej tam filozofii
> tworzenia oprogramowania.
> Rozdział na temat programowania obiektowego:
> http://www.catb.org/~esr/writings/taoup/html/unix_an
d_oo.html

Tu Rich Hickey pisze o niedobrej cesze programowania obiektowego, jaką jest
sklejanie stanu/wartości z tożsamością obiektu:

http://clojure.org/state

A tu Paul Graham dzieli się swoimi doświadczeniami:

http://www.paulgraham.com/noop.html

pozdrawiam,
Daniel

do góry

On Sun, 10 Apr 2011 02:42:17 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>On 9 Kwi, 22:30, Wit Jakuczun <w...@g...com> wrote:
>
>> No ok tylko, e dop ki w wymaganiach wst pnych nie jest napisane, e od
>> kandydat w wymagane jest to, e ju "klepali kod" to program studi w
>> tworzony jest tak jakby tego NIGDY nie robili.
>
>Etam. To jest sztuczna poprawność, kompletnie niepotrzebna.
>Założenie, że na studia idą kompletni idioci ale z wielkim potencjałem
>jest zbędne.

NA uniwersytetach amerykanskich, swiezo przyjeci studenci przechodza
wewnetrzny test czytania, pisania i liczenia. Srednio w skali krajowej
40% przyjetych na studia oblewa ten test, wiec ich sie wysyla na
"remedial year" zeby sie nauczyli. Po tym roku polowa testu nie zdaje,
wiec im sie "remedial year" powtarza. I tak do skutku.

Sluze dokladniejszymi informacjami i anegdotami.

Gdy zapytalem moego kolege uczacego na uniwersytecie lokujacym sie w
pierwszej piatce "czy studenci u was sa taz tak glupi" odparl: "gorzej
- bo nie dosc ze glupi to maja bogatych i wplywowych tatusiow".

A Kolega chce zeby umieli programowac...

A.L.

P.S.

http://www.gazette.net/stories/02252011/polinew19314
2_32534.php

do góry

On Sat, 09 Apr 2011 16:05:27 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>On 08/04/2011 18:39, Wojciech Jaczewski wrote:
>> Sebastian Kaliszewski wrote:
>>
>>> Zresztą, z własnego doświadczenia i obserwacji twierdzę, że zysk (dla
>>> jakości studenta uniwersyteckiego[**]) z uprzedniej znajomości wklepywania
>>> kodu przeważnie jest co najmniej mocno wątpliwy (i mam podejrzenie
>>> graniczące z pewnością, że w wielu wypadkach ujemny).
>>
>> A czy jest zysk/strata dla człowieka, który później pracuje jako
>> programista?
>> Bo wiadomo - na uczelni pisze się w stylu uczelnianym - przerost formy nad
>> treścią jest przez prowadzących lubiany. Natomiast ktoś, kto uczył się
>> samodzielnie, zwykle ma styl nieco inny.
>
>Jest dokładnie odwrotnie: na uczelni największe znaczenie ma zwykle
>treść, w praktyce inżynierii oprogramowania forma jest bardziej istotna.


Qrde, to jakis nonsens z ta "forma" i "trescia". "Tresc" ma byc taka
ze program robi to co ma robic, "forma" ma byc taka za program ma sie
wykonywac szybko i niezawodnie, ma byc tak prosty jak sie da ale nie
prostszy, a tekst programu ma byc czytelny.

Jakos nei widze spzrecznosci miedzy jednym a drugim, ani specjalnei
nie widze roznicy miedzy uczelniami i biznesem

A.L.

do góry

On Mon, 11 Apr 2011 20:04:19 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:

>Andrzej Jarzabek wrote:
>
>> Z drugiej strony też jest tak, że jak ktoś nie zna albo nie potrafi
>> stosować pewnych technik, to często uważa je za niepotrzebne (np. za
>> "przerost formy nad treścią", co uzadania tym, że sam potrafi się bez
>> nich obejść. I to też jest częsta przypadłość ludzi, którzy "uczyli się
>> sami".
>
>Dzięki temu, że uczyłem się sam, zdołałem się wydostać z pułapki stosowania
>właśnie takiego przerostu formy nad treścią. Bo gdy zacząłem stosować m.in.
>techniki "obiektowe", miałem możliwość porównania efektów z tym, co robiłem
>zanim zacząłem je stosować.

Techniki obiektowe to nei ejst "przerost formy nad trescia". Techniki
obiektowe stosuje sie tam gdzie ulatwiaja one pisanie programu. Nie
stusuje sie ich tam gdzie niczego nie wnosza.

A.L.

do góry

On Tue, 12 Apr 2011 20:06:55 +0000 (UTC), Daniel Janus
<n...@d...pl> wrote:

>Dnia 12.04.2011 Wojciech Jaczewski <w...@o...pl> napisał/a:
>> Tak do poprzedniej wypowiedzi jeszcze dodam, że mam mniej-więcej te same
>> obserwacje, co autor "The Art of Unix Programming", chociaż przeczytałem ten
>> tekst później, niż zacząłem praktykować elementy opisanej tam filozofii
>> tworzenia oprogramowania.
>> Rozdział na temat programowania obiektowego:
>> http://www.catb.org/~esr/writings/taoup/html/unix_an
d_oo.html
>
>Tu Rich Hickey pisze o niedobrej cesze programowania obiektowego, jaką jest
>sklejanie stanu/wartości z tożsamością obiektu:
>
> http://clojure.org/state
>
>A tu Paul Graham dzieli się swoimi doświadczeniami:
>
> http://www.paulgraham.com/noop.html
>

Cenie Paula Grahama, ale mniej wiecej 50% jego pisania to czyste
nonsensy. Ten fragment wlasnei nalezy do tej grupy

A.L.

do góry

A. L. wrote:

> Qrde, to jakis nonsens z ta "forma" i "trescia". "Tresc" ma byc taka
> ze program robi to co ma robic, "forma" ma byc taka za program ma sie
> wykonywac szybko i niezawodnie, ma byc tak prosty jak sie da ale nie
> prostszy, a tekst programu ma byc czytelny.

Sprecyzuję, co ja rozumiem pod pojęciem "przerost formy nad treścią".
Program napisany na wyczucie, bez zastosowania różnych "dobrych praktyk"
można zapisać w X linii kodu. Ktoś jednak upiera się by zrobić to np.
"obiektowo" i wychodzi mu 3*X linii. W takim kodzie nie widać, co się
rzeczywiście dzieje, bo jego duża część to bezużyteczne wypełniacze.

do góry

On 12/04/2011 20:17, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>>
>> Nie wiem co stosowałeś, jak i dlaczego, ale jeśli chcesz powiedzieć, że
>> techniki obiektowe to taki właśnie przerost formy nad treścią, którego
>> uczą na uczelniach, ale w praktyce komercyjnej nie mają innego
>> znaczenia, to nie da się tego nazwać inaczej niż bzdurą.
>
> Nie twierdzę, że się ich nie stosuje, tylko że często się je stosuje
> niepotrzebnie.

Być może. Ale ja z kolei twierdzę, że jest to mniej częste, niż ci się
wydaje.

> A da się też robić dobre programy bez nich.

Pytanie czy równie dobre i czy równie sprawnie. Ja uważam, że nie.

> Oczywiście, jeśli w jakiejś firmie kierownictwo się uprze, że programy mają
> być obiektowe, to inaczej nie można.
> Na szczęście nie wszędzie jest taki wymóg (nie znam statystyk).

Statystyke też nie znam, ale na ile się orientuję, ogromna większość
oprogramowania w prawie wszystkich dziedzinach stosuje w jakimś stopniu
techniki obiektowe.

> U mnie na
> szczęście zagadnienia dają się podzielić na osobne, działające wspólnie w
> systemie procesy, więc nie trzeba prowadzić wojen o strukturę programu -
> każdy wykonuje taką, jaka mu pasuje.

Pozwolę sobie w związku z tym zauważyć dwie rzeczy: po pierwsze, sporo
oprogramowania nie jest tak pisane. Gdyby specjalnie w ten sposób
wszystko projektować żeby unikać sytuacji kiedy kod jednego programisty
jest wykorzystywany przez kod innego programisty, to bardzo negatywnie
wpłynęłoby to na wydajność i niezawodność tego oprogramowania.

Po drugie nawet tam, gdzie projektuje się właśnie w ten sposób, często
dąży się do poprawy wydajności i niezawodności przez code reuse. I
techniki obiektowe bywają bardzo przydatne do tych celów.

>> rzeczywistości większość oprogramowania komercyjnego tworzy się z
>> użyciem technik obiektowych i mają one kolosalne znaczenie dla
>> wydajności tworzenia programów i ich niezawodności.
>
> W pozytywny wpływ technik obiektowych na niezawodność zwyczajnie nie wierzę.
> Z moich obserwacji, awaryjność moich programów powstałych po odrzuceniu
> większości technik obiektowych wyraźnie spadła, natomiast ogromnie poprawiła
> się elastyczność - w sensie, że pojawiają się nowe wymagania i trzeba
> program szybko do nich dostosować. Tworząc jakieś hierarchie obiektów,
> ciągle natrafia się na coś, czego się nie przewidziało i trzeba prawie
> całkowicie przebudowywać program.

A według mnie w 99 przypadkach na 100 takie opinie wynikają ze słabego
zrozumienia i nieumiejętności efektywneego posługiwania się technikami
obiektowymi, w dużej części właśnie wynikające z tego, że ktoś się sam
nauczył i potem nie chciał zmieniać przyzwyczajeń. Oczywiście nie mówię,
że to ty. Może i nawet jesteś tym 1 przypadkiem na 100, ale nawet w tym
przypadku zaleta technik obiektowych jest taka, że jesteś 1 przypadkiem
na 100.

Oczywiście istnieją nie-obiektowe alternatywy dla rozwiązań, które dają
techniki obiektowe, np. w językach takich jak Lisp, ale też mają swoje
wady, np. brak silnego systemu typów powoduje, że łatwiej o potencjalnie
trudne do wykrycia błędy wynikające z nieprawidłowego użycia
interfejsów, o problemach z wydajnością nie wspominając. Przede
wszystkim jednak z tego, co napisałeś zgaduję, że to są rzeczy zupełnie
"po drugiej stronie Bluba" niż to, o czym pisałeś - jeszcze bardziej
"akademickie" i "przerost formy nad treścią" niż OO.

>> I owszem, jak ktoś
>> chce pracować jako programista, a nie umie porządnie stosować technik
>> obiketowych, to jest dla niego strata
>
> A może po prostu ci miłośnicy technik obiektowych nigdy nie nauczyli się
> porządnie stosować technik nie-obiektowych i to ich strata?

Oczywiście każda technika, której się porządnie nie nauczysz, to jakaś
tam strata. Tylko że właśnie wracając do punktu wyjścia, samodzielnie
klepiąc kod niczego się porządnie nie nauczysz.

>> i często też strata dla tych, co
>> mu dadzą pracę.
>
> Jeśli liczyli na to, że będzie pokornie programował obiektowo, to tak.
> Natomiast jeśli chcą aby efekty jego programowania były dobre - już
> niekoniecznie.

Wystarczy, że liczą, że "dobre efekty" zawierają w sobie również to, że
kod napisany przez tego osobnika będzie poprawnie korzystał z kodu
napisanego przez innych członków zespołu i że inni członkowie zespołu
(być może nie tacy geniusze jak ów osobnik) będą łatwo i nie generując
dodatkowych błędów wykorzystać ten kod. Również wiele lat po napisaniu
danego kodu i po rozlicznych modyfikacjach kodu wykorzystywanego,
korzystającego jak i częsci samego tego komponentu.

do góry