A.L. <l...@a...com> wrote:
> On Mon, 08 Aug 2011 10:03:32 +0200, m...@t...pl wrote:
>
>>potem i tak dobrze zaplacimy za kazda godzine pracy..." Piekna to
>>byla by praca... tylko siedzenie i ciecie banalnego kodu
>>na procedury... Czasami jestem bardzo zmeczony z powodu
>>presji na efektywnosc czasowa... Chcialbym tak sobie siedziec i
>>przez 90% czasu ciac na male fragmenty i dobrze zarabiac, tak
>>dobrze jak zarabiaja w Ameryce, naprawde bardzo ubolewam
>>ze nie pracujemy razem.
>
> Niestety, nawet w Ameryce praca nie sprowadza sie do ciecia kodu. Ale
> tu sie kodu nie "tnie". Tu sie projektuje porzadnie. Od samego
> poczatku.
>
> Ale ja bardzo przeparszam. Ja predzej uwierze ze w Smolensku byl
> zamach niz ze:
>
> a) procedura dluga na 1000 linii to jest porzadny projekt,
> b) ze taka procedura jest czytelna i latwa do zrozumienia
> c) Ze taka procedura jest latwa do testowania, modyfikacji i
> utrzymania
> d) ze soft zawierajacy taka procedure nie moze byc zaprojektowany
> inaczej.
... nigdy nie mow nigdy;-) Kiedys dawno dawno temu, w tamtym tysiacleciu,
robilo sie takie rzeczy w asm dla niektorych procesorow - brak petli, przy
optymalizacji predkosciowej;-) Z powazaniem
Adam Przybyla

do góry

W dniu 2011-08-08 16:56, Adam Przybyla pisze:
> A.L.<l...@a...com> wrote:
>> On Mon, 08 Aug 2011 10:03:32 +0200, m...@t...pl wrote:
>>
>>> potem i tak dobrze zaplacimy za kazda godzine pracy..." Piekna to
>>> byla by praca... tylko siedzenie i ciecie banalnego kodu
>>> na procedury... Czasami jestem bardzo zmeczony z powodu
>>> presji na efektywnosc czasowa... Chcialbym tak sobie siedziec i
>>> przez 90% czasu ciac na male fragmenty i dobrze zarabiac, tak
>>> dobrze jak zarabiaja w Ameryce, naprawde bardzo ubolewam
>>> ze nie pracujemy razem.
>>
>> Niestety, nawet w Ameryce praca nie sprowadza sie do ciecia kodu. Ale
>> tu sie kodu nie "tnie". Tu sie projektuje porzadnie. Od samego
>> poczatku.
>>
>> Ale ja bardzo przeparszam. Ja predzej uwierze ze w Smolensku byl
>> zamach niz ze:
>>
>> a) procedura dluga na 1000 linii to jest porzadny projekt,
>> b) ze taka procedura jest czytelna i latwa do zrozumienia
>> c) Ze taka procedura jest latwa do testowania, modyfikacji i
>> utrzymania
>> d) ze soft zawierajacy taka procedure nie moze byc zaprojektowany
>> inaczej.
> ... nigdy nie mow nigdy;-) Kiedys dawno dawno temu, w tamtym tysiacleciu,
> robilo sie takie rzeczy w asm dla niektorych procesorow - brak petli, przy
> optymalizacji predkosciowej;-) Z powazaniem

Ale wtedy raczej pisało się generator kodu, albo makro, które rozwijało
się do takiej procedury. Z punktu widzenia "źródła źródła" procedura
(w postaci makra czy nawet generatora) była krótka.

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

do góry

On Mon, 8 Aug 2011 14:56:55 +0000 (UTC), Adam Przybyla
<a...@r...pl> wrote:

>A.L. <l...@a...com> wrote:
>> On Mon, 08 Aug 2011 10:03:32 +0200, m...@t...pl wrote:
>>
>>>potem i tak dobrze zaplacimy za kazda godzine pracy..." Piekna to
>>>byla by praca... tylko siedzenie i ciecie banalnego kodu
>>>na procedury... Czasami jestem bardzo zmeczony z powodu
>>>presji na efektywnosc czasowa... Chcialbym tak sobie siedziec i
>>>przez 90% czasu ciac na male fragmenty i dobrze zarabiac, tak
>>>dobrze jak zarabiaja w Ameryce, naprawde bardzo ubolewam
>>>ze nie pracujemy razem.
>>
>> Niestety, nawet w Ameryce praca nie sprowadza sie do ciecia kodu. Ale
>> tu sie kodu nie "tnie". Tu sie projektuje porzadnie. Od samego
>> poczatku.
>>
>> Ale ja bardzo przeparszam. Ja predzej uwierze ze w Smolensku byl
>> zamach niz ze:
>>
>> a) procedura dluga na 1000 linii to jest porzadny projekt,
>> b) ze taka procedura jest czytelna i latwa do zrozumienia
>> c) Ze taka procedura jest latwa do testowania, modyfikacji i
>> utrzymania
>> d) ze soft zawierajacy taka procedure nie moze byc zaprojektowany
>> inaczej.
> ... nigdy nie mow nigdy;-) Kiedys dawno dawno temu, w tamtym tysiacleciu,
>robilo sie takie rzeczy w asm dla niektorych procesorow - brak petli, przy
>optymalizacji predkosciowej;-) Z powazaniem
> Adam Przybyla

Owszem. To bylo bardzo dawno. Sam osobiscie, w GWBASIC napisalem
program skladajacy sie z ciurka prawie 10 tysiecy linii. Ale GWBASIC
nie mial procedur.

Od tego czasu jednak to i owo sie zmienilo. W COBOLU na przykald
programwoalo sie skomplikwoane warunki poslugujac sie tablicami
decyzyjnymi i kompilatorem tablic decyzyjnych. Jedna z czynnosci
takiego kompilatora byla dekompozycja tablic na zbior tablic o
prostszej strukturze, po to zeby bylo je latwiej zrozumiec i testowac.
Nawet w COBOLU i Fortranie czasy 100 stronicowych procedur dawno
minely.

Problem zas generalny jest taki ze "miszcze porogramowania" uwazaja ze
obiektowosc oferowana pzrez jezyki to tylko triki programistyczne
ulatwiajace (a raczej na ogol gmatwajace) pisanie kodu. Mysia zas
ciagle tymi samymi kategoriami ktorymi myslalo sie w czasach GWBASICa.

Mam dowody na to tu gdzie pracuje, nie tzreba szykac dowodow na
grupach usenetowych...

A.L.

do góry

On Mon, 08 Aug 2011 18:30:01 +0200, Pawe? Kierski <n...@p...net>
wrote:

>W dniu 2011-08-08 16:56, Adam Przybyla pisze:
>> A.L.<l...@a...com> wrote:
>>> On Mon, 08 Aug 2011 10:03:32 +0200, m...@t...pl wrote:
>>>
>>>> potem i tak dobrze zaplacimy za kazda godzine pracy..." Piekna to
>>>> byla by praca... tylko siedzenie i ciecie banalnego kodu
>>>> na procedury... Czasami jestem bardzo zmeczony z powodu
>>>> presji na efektywnosc czasowa... Chcialbym tak sobie siedziec i
>>>> przez 90% czasu ciac na male fragmenty i dobrze zarabiac, tak
>>>> dobrze jak zarabiaja w Ameryce, naprawde bardzo ubolewam
>>>> ze nie pracujemy razem.
>>>
>>> Niestety, nawet w Ameryce praca nie sprowadza sie do ciecia kodu. Ale
>>> tu sie kodu nie "tnie". Tu sie projektuje porzadnie. Od samego
>>> poczatku.
>>>
>>> Ale ja bardzo przeparszam. Ja predzej uwierze ze w Smolensku byl
>>> zamach niz ze:
>>>
>>> a) procedura dluga na 1000 linii to jest porzadny projekt,
>>> b) ze taka procedura jest czytelna i latwa do zrozumienia
>>> c) Ze taka procedura jest latwa do testowania, modyfikacji i
>>> utrzymania
>>> d) ze soft zawierajacy taka procedure nie moze byc zaprojektowany
>>> inaczej.
>> ... nigdy nie mow nigdy;-) Kiedys dawno dawno temu, w tamtym tysiacleciu,
>> robilo sie takie rzeczy w asm dla niektorych procesorow - brak petli, przy
>> optymalizacji predkosciowej;-) Z powazaniem
>
>Ale wtedy raczej pisało się generator kodu, albo makro, które rozwijało
>się do takiej procedury. Z punktu widzenia "źródła źródła" procedura
>(w postaci makra czy nawet generatora) była krótka.

Zreszta dzis sie podobne rzeczy robi na przyklad w C++ uzywajac
"template metaprogramming"

A.L.

do góry

A.L. <l...@a...com> wrote:
> On Mon, 8 Aug 2011 14:56:55 +0000 (UTC), Adam Przybyla
> <a...@r...pl> wrote:
>
>>A.L. <l...@a...com> wrote:
>>> On Mon, 08 Aug 2011 10:03:32 +0200, m...@t...pl wrote:
>>>
>>>>potem i tak dobrze zaplacimy za kazda godzine pracy..." Piekna to
>>>>byla by praca... tylko siedzenie i ciecie banalnego kodu
>>>>na procedury... Czasami jestem bardzo zmeczony z powodu
>>>>presji na efektywnosc czasowa... Chcialbym tak sobie siedziec i
>>>>przez 90% czasu ciac na male fragmenty i dobrze zarabiac, tak
>>>>dobrze jak zarabiaja w Ameryce, naprawde bardzo ubolewam
>>>>ze nie pracujemy razem.
>>>
>>> Niestety, nawet w Ameryce praca nie sprowadza sie do ciecia kodu. Ale
>>> tu sie kodu nie "tnie". Tu sie projektuje porzadnie. Od samego
>>> poczatku.
>>>
>>> Ale ja bardzo przeparszam. Ja predzej uwierze ze w Smolensku byl
>>> zamach niz ze:
>>>
>>> a) procedura dluga na 1000 linii to jest porzadny projekt,
>>> b) ze taka procedura jest czytelna i latwa do zrozumienia
>>> c) Ze taka procedura jest latwa do testowania, modyfikacji i
>>> utrzymania
>>> d) ze soft zawierajacy taka procedure nie moze byc zaprojektowany
>>> inaczej.
>> ... nigdy nie mow nigdy;-) Kiedys dawno dawno temu, w tamtym tysiacleciu,
>>robilo sie takie rzeczy w asm dla niektorych procesorow - brak petli, przy
>>optymalizacji predkosciowej;-) Z powazaniem
>> Adam Przybyla
>
> Owszem. To bylo bardzo dawno. Sam osobiscie, w GWBASIC napisalem
> program skladajacy sie z ciurka prawie 10 tysiecy linii. Ale GWBASIC
> nie mial procedur.
>
> Od tego czasu jednak to i owo sie zmienilo. W COBOLU na przykald
> programwoalo sie skomplikwoane warunki poslugujac sie tablicami
> decyzyjnymi i kompilatorem tablic decyzyjnych. Jedna z czynnosci
> takiego kompilatora byla dekompozycja tablic na zbior tablic o
> prostszej strukturze, po to zeby bylo je latwiej zrozumiec i testowac.
> Nawet w COBOLU i Fortranie czasy 100 stronicowych procedur dawno
> minely.
>
> Problem zas generalny jest taki ze "miszcze porogramowania" uwazaja ze
> obiektowosc oferowana pzrez jezyki to tylko triki programistyczne
> ulatwiajace (a raczej na ogol gmatwajace) pisanie kodu. Mysia zas
> ciagle tymi samymi kategoriami ktorymi myslalo sie w czasach GWBASICa.
>
> Mam dowody na to tu gdzie pracuje, nie tzreba szykac dowodow na
> grupach usenetowych...
... ok. Tak tylko misie przypomnialo;-) Z powazaniem
Adam Przybyla

do góry

Dnia Mon, 08 Aug 2011 08:27:00 -0500, A.L. napisał(a):
> Niestety, nawet w Ameryce praca nie sprowadza sie do ciecia kodu. Ale
> tu sie kodu nie "tnie". Tu sie projektuje porzadnie. Od samego
> poczatku.

Srali muchy, będzie wiosna.

Widziałem te "hamerykańskie" "tu się projektuje porządnie".
Owszem, część to przemyślana robota. I chylę czoła przed tymi, których
solidną pracę projektową miałem okazję oglądać.
Ale druga część to gnioty takie, że już lepiej nie projektować wcale.
Kod naklepany na kolanie przez w miarę łebskiego programistę
będzie miał większy sens niż wydumane "dizajny" z piekła rodem,
gdzie projektuje się każdą poszczególną funkcję programu,
który w efekcie robi kulawo coś, co dawno zostało zrobione.

Jak to w filmach Chęcińskiego było, ludzie dzielą
się nie na swoich i cudzych, a na mądrych i głupich.

Swoją drogą, trzeba mieć niezłe kompleksy, żeby leczyć je tekstami
w rodzaju "bo tu u nas w Ameryce". Zwłaszcza po polsku.

Pozdrawiam,
Waldek

do góry

> On Mon, 08 Aug 2011 10:03:32 +0200, m...@t...pl wrote:

> Ale ja bardzo przeparszam. Ja predzej uwierze ze w Smolensku byl
> zamach niz ze:


> a) procedura dluga na 1000 linii to jest porzadny projekt,
> b) ze taka procedura jest czytelna i latwa do zrozumienia
> c) Ze taka procedura jest latwa do testowania, modyfikacji i
> utrzymania
> d) ze soft zawierajacy taka procedure nie moze byc zaprojektowany
> inaczej.

AD a) Projekt jest na tyle porzadny, na ile porzadny mozna zrobic
bez znacznego narzutu czasu na jego wykonanie i bez pewnosci
co przyniesie przyszlosc (zmiany w projekcie)
AD b) Nie jest to latwa procedura do zrozumienia. Jesli
ktos nie wie jaki byl zamysl autora, to nawet nie ma najmniejszej
mozliwosci na zrozumienie. Jesli ktos znajdzie usterke i
bedzie chcial naniesc poprawke, to bedzie musial szybko
odnalezc wlasciwe miejsce w tej procedurze. Pomoga mu w
tym komentarz. Oczywiscie jesli ktos nie wie co robi program
to nic mu nie pomoze, ani funckje, ani komentarz. Musi byc
przeszkolony.
AD c1)Do testowania i modyfikacji jest tak samo trudna jak N malych
procedur. Jest to specyficzny kod, nie ma tam np. ani jednej
petli, nie ma zadnej tablicy, nie musze zamykac uchwytow
do plikow, nie musze zwalniac pamieci...
AD c2)Nie widze jakiejkolwiek mozliwosci utrzymania tego kodu. Kod
robi bardzo specjalistyczna rzecz i do niczego innego sie nie
nadaje. Nie widze mozliwosci wykrzystania tego kodu w innych
miejscach projektu. Zapewniam ze jak taka mozliwosc
zobacze to nie tylko podziele na funkcje, ale zrobie z tego
hierarchie klas i programowanie roznicowe. Czasami sie myle w
ocenie ze kodu nie da sie wykorzystac ponownie, jesli tu
sie pomylilem, to tez zmeinie.
AD d) Moze byc zaprojektowany lepiej, ale intuicyjnie czuje jakas
odraze do ekstremalnie dopasowanych projektow. Mam silne wrazenie,
ze zamiast wczytywac sie w trudny i duzy fragment kodu (szczegolnie
nie pierwotworcy) lepiej jest, gdy ma sie dobry scheamt postepowania i,
albo wywala sie jakas funkcjonalnosc, albo dodaje od nowa. Oczywiscie
ten kod ktory powtarza sie przy dodawaniu nowej funkcjonalnosci jest
umieszczony w roznego rodzaju klasach/metodach i nalezy z niego
korzystac. Nie mam takiego projektu ze sa w nim same procedury po
tysiac wierszy :)

Pozdrawiam



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

do góry

On Mon, 8 Aug 2011 21:51:56 +0200, "Waldek M."
<w...@l...localdomain> wrote:

>Dnia Mon, 08 Aug 2011 08:27:00 -0500, A.L. napisał(a):
>> Niestety, nawet w Ameryce praca nie sprowadza sie do ciecia kodu. Ale
>> tu sie kodu nie "tnie". Tu sie projektuje porzadnie. Od samego
>> poczatku.
>
>Srali muchy, będzie wiosna.
>

Dziekuje za konkretny, merytoryczny wklad do dyskusji. Jestem pelen
podziwu.

>Widziałem te "hamerykańskie" "tu się projektuje porządnie".
>Owszem, część to przemyślana robota. I chylę czoła przed tymi, których
>solidną pracę projektową miałem okazję oglądać.
>Ale druga część to gnioty takie, że już lepiej nie projektować wcale.
>Kod naklepany na kolanie przez w miarę łebskiego programistę
>będzie miał większy sens niż wydumane "dizajny" z piekła rodem,
>gdzie projektuje się każdą poszczególną funkcję programu,
>który w efekcie robi kulawo coś, co dawno zostało zrobione.
>
>Jak to w filmach Chęcińskiego było, ludzie dzielą
>się nie na swoich i cudzych, a na mądrych i głupich.
>
>Swoją drogą, trzeba mieć niezłe kompleksy, żeby leczyć je tekstami
>w rodzaju "bo tu u nas w Ameryce". Zwłaszcza po polsku.
>
>Pozdrawiam,
>Waldek

Reszta "argumentow" rownie imponujaca jak otwarcie. Zapewnia Koledze
doczesne miejsce w moim KF

A.L.

do góry

Dnia Mon, 08 Aug 2011 16:35:13 -0500, A.L. napisał(a):

> On Mon, 8 Aug 2011 21:51:56 +0200, "Waldek M."
> <w...@l...localdomain> wrote:

>>> Niestety, nawet w Ameryce praca nie sprowadza sie do ciecia kodu. Ale
>>> tu sie kodu nie "tnie". Tu sie projektuje porzadnie. Od samego
>>> poczatku.
[...]
> Reszta "argumentow" rownie imponujaca jak otwarcie.
Nooo.. bo Twoich argumentów było mnóstwo i miały rzeczowe
pokrycie w faktach.

> Zapewnia Koledze doczesne miejsce w moim KF
Zdaje się, że należę do większości, a jeśli już nawet
Seweryna tam wysłałeś, to w pewien sposób jest to dla mnie
nobilitacja :-)
Ciekaw jestem tylko, po co subskrybować grupę, jeśli potem
kolejno wrzuca się ludzi do KF. Taki publiczny blog,
gdzie można napawać się swoją fachowością i tym,
jak to w Hameryce cudnie?

Waldek

do góry

> > Reszta "argumentow" rownie imponujaca jak otwarcie.

> Nooo.. bo Twoich argumentów było mnóstwo i miały rzeczowe

> pokrycie w faktach.


kenobi: and my time is a piece of wax, fallin' on a termite,
that's chokin on the splinters


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

do góry