On 12/04/2011 22:47, A.L. wrote:
> On Sat, 09 Apr 2011 16:05:27 +0100, Andrzej Jarzabek
>>
>> 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.

Z grubsza o to mi chodziło.

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

Nie mam jakiegoś super wielkiego doświadczenia z uczelniami, więc może
nie mam tutaj racji, ale różnica wydaje mi się taka, że projekty
progrmaistyczne robione przez studentów zwykle krócej trwają, pracuje
przy nich mniejsza ilośc ludzi i nie ma takich problemów ze
zmieniającymi się wymaganiami czy rotacją w zespole, więc student ma
mniejsze szanse, że problemy wynikające z niedostatków formy w jego
kodzie, takimi właśnie jak nieczytelność czy wady projektowe, przyjdą i
ugryzą go w tyłek.

Nie mówię oczywiście, że w biznesie jest z tym różowo, ale że właśnie
forma jest ważniejsza (niż na uczelni) bo generujee lub przeciwnie,
pozwala unikać realnych problemów.

Sprzeczności między jednym a drugim nie ma żadnej, ale też właśnie
dlatego piszę, to co piszę, o biznesie: to, że program ma działać i
robić to, co ma robić, to wiadomo, ale ważne też jest jeszcze żeby był
pisany w sposób ułatwiający dalsze modyfikacje i utrudniający
wprowadzanie do niego błędów. Na uczelni (tu moje wrażenia nie popartee
porządnymi badaniami na reprezentatywneej próbie) braki formalne w
zależności od zajęć czy prowadzącego mogą przejść bez bólu, o ile
program robi to, co ma robić i spełnia formalne wymogi zadania, bo
program nie jest w większości przypadków dalej rozwijany, porządnie
testowany ani intensywnie użytkowany.

do góry

On 12/04/2011 23:18, Wojciech Jaczewski wrote:
>
> 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.

Taki jest właśnie problem z samodzielnymi klepaczami: nie wiedzą gdzie
należy czego używać, nie mają pojęcia na temat dobrych praktyk więc
wymyślają na ich temat jakieś mity, nie potrafią czytać kodu, a
wszystko, czego sami nie potrafią sensownie użyć jawi im się
"bezsensownym wypełniaczem".

do góry

On Wed, 13 Apr 2011 00:25:35 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>On 12/04/2011 23:18, Wojciech Jaczewski wrote:
>>
>> 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.
>
>Taki jest właśnie problem z samodzielnymi klepaczami: nie wiedzą gdzie
>należy czego używać, nie mają pojęcia na temat dobrych praktyk więc
>wymyślają na ich temat jakieś mity, nie potrafią czytać kodu, a
>wszystko, czego sami nie potrafią sensownie użyć jawi im się
>"bezsensownym wypełniaczem".

Wlasnie. Dlatego "domoroslych programistow", gdy przyjda na studia,
nalezy najpierw oduczyc "domoroslego programowania". Wiekszy z nimi
klopot niz z takim ktory zaczyna od zera

A.L.

do góry

W dniu 2011-04-10 11:42, Maciej Sobczak pisze:
> 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.
To nie jest sztuczna poprawność. Nie słyszałem, żeby na jakiekolwiek
studia informatyczne robione egzaminy wstępne z programowania. Dlatego
należy przyjąć, że WSZYSCY reprezentują poziom "nie umiem". Należy, gdyż
jest to jedyne możliwe ograniczenie na poziom umiejętności programowania
wśród kandydatów. Trywialne co prawda ale poprawne.

Zresztą ja kończyłem matematykę na UW i tam zakładano, że ludzie NIE
znają matematyki. Oczywiście byli tacy, dla których to założenie było
zbyt pesymistyczne. I dla nich były specjalne zajęcie z tzw. "gwiazdką".


Pozdrawiam,
Wit

do góry

W dniu 2011-04-12 21:17, Wojciech Jaczewski pisze:
> 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.
Dla mnie brzmi to jak horror i dokładna definicja samowolki.
Potem przychodzi na miejsce jednego artysty drugi artysta i robi
poprawki. Tak jak mu pasuje.
REWELACJA.
Tylko, że to wina szefa projektu - a raczej jego brak...

>> 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ć.
Yhm.
Słyszałeś o wzorcach projektowych i umiesz je stosować w praktyce?

> Tworząc jakieś hierarchie obiektów,
> ciągle natrafia się na coś, czego się nie przewidziało i trzeba prawie
> całkowicie przebudowywać program.
Wiesz, jak zaimplementujesz program jako hierarchię obiektów-bogów - to
fakt - będzie to wyglądało jak opisujesz.
Tylko, że to nie ma nic wspólnego z OOP - nic a nic.

>> 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?
A przez porządnie rozumiesz "[...]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"?
Litości...

>> 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.
Jasne.
Jak sobie wyobrażasz spełnienie wymogu programowania obiektowego przez
programistę, który co najwyżej umie używać obiektów.
W ten sposób ów człowiek się męczy a fimra dostaje potworek...

--
wloochacz

do góry

On 13 Kwi, 00:18, Wojciech Jaczewski <w...@o...pl> wrote:
> 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.

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 :)
Pozdrawiam

do góry

On 12 Kwi, 21:17, Wojciech Jaczewski <w...@o...pl> wrote:

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

Mam podobne obserwacje w programach w ktorych wazna jest wydajna
implementacja. Wtedy zdecydowanie wole podejscie proceduralne. Poza
tym wyjatkiem, podejscie obiektowe zawsze mi pomaga.

Pozdrawiam

do góry

On 12 Kwi, 23:49, A.L. <l...@a...com> wrote:
> 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.
>
Dobrze powiedziane. Z tym ze "cos" to chyba zawsze techniki
obiektowe wnasza? Chocby szybsze odszukanie fragmentu kodu
do poprawki po dlugiej przerwie?
Pozdrawiam

do góry

On Apr 12, 10:06 pm, Daniel Janus <n...@d...pl> wrote:

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

Sorki, ale ten tekst to jest marketingowe machanie rękami.
OO niczego nie skleja. Już sam fakt, że promuje komunikację pomiędzy
obiektami za pośrednictwem interfejsu, który enkapsuluje jego stan
świadczy o tym, że pojęcie sklejania czegokolwiek nie ma sensu. Bo
skoro stan jest enkapsulowany, to nie ma sensu rozważać, czy tożsamość
obiektu i jego stan są zintegrowane, czy rozdzielone.
Bez najmniejszego problemu można powiedzieć, że w OO obiekt *ma* (has)
stan. A właściwie to właśnie nie należy tak mówić - bo relacja
pomiędzy obiektem i jego stanem jest ukryta, więc nie wiadomo, jaka
ona naprawdę jest. I o to chodzi.

W ogóle ten esej to zbiór haseł rzuconych bez uzasadnienia a paragraf
o programowaniu imperatywnym jest już całkiem słaby.

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

do góry

On 04/13/2011 08:46 AM, wloochacz wrote:
> W dniu 2011-04-12 21:17, Wojciech Jaczewski pisze:
>> 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?
> A przez porządnie rozumiesz "[...]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"?
> Litości...

Bez przesady, wracasz do starego wątku "czy pisać wszystko w C++/Javie,
czy może jednak użyć narzędzia specjalizowanego, czyt. Prolog".

JD

do góry