Pan Sebastian Biały napisał:

>>> Czekaj, skąd wytrzasnałeś brak umiejętności analizy założeń?
>> Z dyskusji w tym wątku (ale też trochę z wcześniejszych obserwacji).
>> A dokładnie z ignorowania wcześniej opisanych warunków przy formułowaniu
>> własnych sądów.
>
> A jakie warunki były opisane? Bo ja się wtryniłem z butami w dyskusję
> która dawno wykraczala poza potrzebe inicjatora wątku i wy tam sobie
> wesoło ględziliście o wyższośc LPT nad atmelkami w sytuacjach ogólnych.

Nie mogę każdemu wszystkiego tłumaczyć i nakazywać jakie ma zająć
stanowisko w dyskusji. Może sobie ględziliśmy wesoło, może o wyższości,
ale jak się wchodzi w dyskusję (z butami lub bez), to dobrze jest
robić to tak, by odnieść się do tego, co mówia inni. A nie po to,
by zamianifestować swoje poglądy (uprzedzenia, kompleksy czy co to
tam jest).

>>>>> NIE. Chodzi o to by nie dopuścić do pomyłek w momecie pisania.
>>>> Z takim podejściem w ogóle nie ma co się zabierać za pisanie programu.
>>> Prezentujesz poziom zblizony do poglądow programistów z lat 80.
>> Programowałem również wcześniej.
>
> To bardzo wiele tłumaczy. Szczególnie styl: jak zabraknie argumentu to
> ucieczka w "za młody jesteś żeby pamiętać jak żeśmy z Józkiem klepali
> sterowniki na PDP w kodzie maszynowym na kartach perforowanych".

Wręcz przeciwnie -- niech teraz młodzi kodują, im to szybciej idzie,
nie zastanawiają się nad każdą rzeczą, tylko piszą i idą do przodu.
Wystarczy takimi pokierować, a efekty są znakomite.

>>> Widuje ich na codzień. Ta dyskusja wraca bardzo czesto i zazwyczaj
>>> kończy się na inwektywach.
>> Mam się spodziewać, że zaraz zacznie Pan rzucać mięsem?
>
> Wręcz przeciwnie, zazwyczaj to reakcja alergiczna strony przeciwnej na
> hasło "przeciez od dawna jest silne typowanie w C++" albo "po co tyle
> niebezpiecznego kodu, nie słyszaleś o RAII?".

Nie mam alergii, nawet na pyłki.

>>> Błedy lepiej blokować niż dopuszczać i debugować. Języki interpretowane
>>> i dynamicznie typowane nie potrafią blokować błedów poza trywialnymi w
>>> składni. Na tej planecie są całe stada programistów którzy sobie tego
>>> nigdy nie uświadomią.
>> Więcej błędów powstaje przy tworzeniu założeń, a nawet przy określaniu
>> wymagań. A jeśli nawet nie więcej, to są one bardziej istotne.
>
> Wow, to była szybka ucieczka w bok. Nie doceniałem doświadczenia
> usenetowego kolegi. Zapomniałeś jednak wyciąć cytatu, było by
> bardziej z sensem.

A co tu jest bez sensu?

>> Bo ja nie oddam swego życia (a nawet rzeczy o wiele mniej cennych)
>> w ręce koderów.
>
> Oddajesz codziennie.

Jeśli już, to bez udziału woli. To całkiem co innego. Ale gdy mogę,
unikam takich sytuacji.

>>> Bo doskonale wiedzialem, po analizie, czego i jak potrzebuje użyć.
>> Świetnie. Widzę, że praca w zespole przynosi efekty.
>
> Jakim zespole?

Jeden analizuje, drugi koduje -- tak jak napisano wyżej.

>>> Pomimo tego nie potrafie nawet naszkicować zbioru warunków na które
>>> odpowiedzią byłby bash.
>> Nie wszyscy potrafią wszystko.
>
> Spodziewałem się raczej przykladu ale jak zwykle zostala tylko żałosna
> złośliwość.

Przykłady (niepotrafienia) są wyżej. Więcej nie potrzeba.

>>> Zawsze jest lepsza alternatywa.
>> Zawsze. Od początku Panu o tym mówiłem.
>
> Nie. Bash nie jest lepszą alternatywą. Naprawdę, w stosunku do
> czegokolwiek. Podobnie jak i perl.

Bash może być lepszą alternatywą dla perla, podobnie perl może być
lepszą alternatywą dla basha.

--
Jarek