On Wed, 13 Apr 2011 21:55:04 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:

>A. L. wrote:
>
>> Z faktu ze L.T. napisal (sciagnal?...) kernel Linuxa nei wynika
>> zupelnie ze a) jest znakomitym programista,
>
>To po czym się rozpoznaje dobrego programistę? Po tym, że dobrze recytuje
>książki?

Tak jak sie odroznia dobrego inzyniera od zlego.

A.L.

do góry

On Wed, 13 Apr 2011 21:13:52 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:
> Taka dość znana postać jak Linus Torvalds pewnie też jest
> samodzielnym klepaczem, bo też da się znaleźć jego
> negatywne opinie na temat m.in. programowania obiektowego.

1. Nie mam zdania, czy Torvalds jest samodzielnym klepaczem, czy nie.
2. Sam fakt negatywnego wypowiadania się o OO tego nie rozstrzyga.
3. Widziałem wiele idiotycznych wypowiedzi Torvaldsa na różne tematy.
4. Linux to jednostkowy przykład, trudno powiedzieć, czy decyzje
Torvaldsa raczej pomogły, czy przeszkodziły w rozwoju i niezawodności
kernela.
5. Niezależnie od wszystkiego, Torvalds jest raczej wyjątkiem niż
regułą, nie wnikając czy to dlatego, że jest wyjątkowo dobry,
wyjątkowo pracowity, czy miał wyjątkowe szczęście.

do góry

On Wed, 13 Apr 2011 21:47:23 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:
> > 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.
>
> Ale tu wcale nie tworzy się barier, aby drugi człowiek korzystał z
> fragmentów pierwszego. Pasuje mu, to korzysta, nie - to nie.

Jak najbardziej tworzy się bariery. Powiedzieć, że nie wolno
korzystać to nie jest jedyny sposób na tworzenie barier. Bariery
tworzą też decyzje powodujące, że korzystanie wymaga dodatkowego
nakładu pracy, albo że wprowadza dodatkowe ryzyko błędów.

Właśnie na ten przykład decyzja, że każdy może robić swój kawałek jak
zechce, byle tylko działał, stanowi taką praktyczną barierę.

> > obiektowymi, w dużej części właśnie wynikające z tego, że ktoś
się sam
> > nauczył i potem nie chciał zmieniać przyzwyczajeń.
>
> Chciałem. Opamiętanie się, zajęło mi około dwa lata (pracy
> zarobkowej + własnych eksperymentów).

Wybacz, ale po pierwsze to co piszesz nie przekonuje mnie, a po
drugie nawet jeśli rzeczywiście chciałeś, to sedno sprawy polega
przecież na tym, ze chęć szczera to za mało.

> Niestety nasza dyskusja skazana jest na bycie nieco jałową, bo
> przecież nie wrzucę na grupę dyskusyjną programów
> wykonywanych w pracy, aby inni mieli szansę zrobić obiektowy
> kontr-przykład do porównania czytelności tych dwóch
> wersji.

Niby nie, ale o pewnych zasadach można mówić bez przeklejania
konkretnego kodu.

> Stosowanie rozwiązań modnych ma swoje zalety, ale czasem
> warto modę odrzucić.

Czasem warto też myśleć o inżynierii w kategoriach innych niż moda.

> > klepiąc kod niczego się porządnie nie nauczysz.
>
> Są w internecie kody źródłowe projektów, które się udały
> i utrzymały się przez wiele lat. Można oglądać i próbować
> naśladować.

Można. Tylko że w ten sposób niczego się porządnie nie nauczysz. To
tak jakbyś chciał nauczyć się budowy mostów oglądając wszystkie mosty
w zasięgu spaceru i eksperymentując z przerzucaniem kładki nad
strumykiem.

do góry

Wojciech Jaczewski wrote:

> Andrzej Jarzabek 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".
>
> Taka dość znana postać jak Linus Torvalds pewnie też jest samodzielnym
> klepaczem, bo też da się znaleźć jego negatywne opinie na temat m.in.
> programowania obiektowego.

Najciekawsze jest to, ze spora czesc kernela jest jak najbardziej OO -
wystarczy chociazby popatrzec na VFS. Tyle ze to OO - ze tak powiem -
"dziergane recznie" - bez wsparcia jezyka.
Tak swoja droga nie slyszalem o LT krytykujacym OO - raczej krytykujacym C++
jako nie nadajacym sie do programowania kernela (wrecz chodzi mi po glowie
jakies jego zdanie ze OO mozna robic w C i dlatego uzywamy C). Co ciekawe -
bylo wiele dyskusji na ten temat i moj wniosek po przejrzeniu kilku jest
taki, ze "kernel hackers" nie chca C++, bo go tak naprawde nie znaja.

> Zdecydowanie chciałbym kiedyś osiągnąć taki poziom jak L.T. a nie jak 99%
> "profesjonalistów", mających pojęcie o "dobrych praktykach".

Chcialem tylko niesmiale zaznaczyc, ze odwolywanie sie do autorytetu (nawet
jesli Linus moze byc za taki uznany) jest slabym argumentem w dyskusji.

--
Michal

do góry

W dniu 2011-04-13 21:30, A.L. pisze:
[...]
> Niby dlaczego?... U mnie w firmie zawsze jest wiecej do srobienai niz
> "mocy przerobowych" co nie przeszkadza miec rozne dokumenty pod
> wspolna nazwa "programming standards" ktorych przestzreganie jest
> wymuszane w sposob drakonski, poczawszy od zautomatyzoanych narzedzi
> po manualne "code reviews". Dzieje sie tak, albowiem zauwazono (nie
> tylko w mojej firmie) ze "strata czasu" zwiazana z porzadnym
> kodowaniem jest znacznie mniejsza nis rzeczywista strata czasu
> znacznie pozniej, gdy przyjdzie modyfikowac program lub szukac bledow.

Wydaje mi się, że również na polu "standaryzacji" trzeba zachować umiar
i dopasować narzędzia do zastosowań. Np. nie widzę specjalnego sensu
w standaryzowaniu pierdół w postaci "Stawiamy spację między 'if'
a nawiasem czy nie?". Choć już otwieranie bloków (nawias w tej samej
linii lub następnej) bywa istotne dla czytelności kodu przez większość
- wypada się zastanowić, czy warto wymuszać na ludziach, czy może
przygotować środowisko tak, żeby każdy pisał, jak chce, a automat
utrzymywał spójność w repozytorium.

Po za tym - inaczej to będzie wyglądało w zespole kilkuosobowym,
a inaczej w projekcie tworzonym we współpracy kilkunastu takich
zespołów. Mniejsze projekty mogą sobie pozwolić na nieco większą
elastyczność.

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

do góry

dodam dla formalnosci ze moje ostatnie czeste wypowiedzi nt glupoty
z ktora jestem zmuszony obcowac _to nie jest cos co bym lubil_ -
nie cierpie tego bo nienawidze juz wchodzenia na samo pole glupoty
(a jeszcze bardziej na pole klozetu) niestety chwilowo zabraklo mi
mysli jak przeciwstawic sie tutejszym pomrocznym malomozgom na swoim
wlasnym polu (doknela mnie swoista mentalna korupcja od glupich ale
moze uda mi sie odbudowac)

fir

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

do góry

W dniu 2011-04-14 08:44, Paweł Kierski pisze:
> W dniu 2011-04-13 21:30, A.L. pisze:
> [...]
>> Niby dlaczego?... U mnie w firmie zawsze jest wiecej do srobienai niz
>> "mocy przerobowych" co nie przeszkadza miec rozne dokumenty pod
>> wspolna nazwa "programming standards" ktorych przestzreganie jest
>> wymuszane w sposob drakonski, poczawszy od zautomatyzoanych narzedzi
>> po manualne "code reviews". Dzieje sie tak, albowiem zauwazono (nie
>> tylko w mojej firmie) ze "strata czasu" zwiazana z porzadnym
>> kodowaniem jest znacznie mniejsza nis rzeczywista strata czasu
>> znacznie pozniej, gdy przyjdzie modyfikowac program lub szukac bledow.
>
> Wydaje mi się, że również na polu "standaryzacji" trzeba zachować umiar
> i dopasować narzędzia do zastosowań. Np. nie widzę specjalnego sensu
> w standaryzowaniu pierdół w postaci "Stawiamy spację między 'if'
> a nawiasem czy nie?". Choć już otwieranie bloków (nawias w tej samej
> linii lub następnej) bywa istotne dla czytelności kodu przez większość
> - wypada się zastanowić, czy warto wymuszać na ludziach, czy może
> przygotować środowisko tak, żeby każdy pisał, jak chce, a automat
> utrzymywał spójność w repozytorium.
>
> Po za tym - inaczej to będzie wyglądało w zespole kilkuosobowym,
> a inaczej w projekcie tworzonym we współpracy kilkunastu takich
> zespołów. Mniejsze projekty mogą sobie pozwolić na nieco większą
> elastyczność.
Nie zgadzam się z Tobą - ja mam mikry zespół składający się z kilku
osób, ale mam też pewien dokument w którym w dość restrykcyjny sposób
opisałem wszystkie takie jak je nazywasz - pierdoły.
Zgodziłem się na jeden kompromis - wszystko to co opisałem, uzyskuję za
pomocą automatycznego formatowania kodu wbudowanego w IDE.
Nie było moim celem zmuszanie kogokolwiek do trzymania się pierdół,
tylko do zachowania konwencji.
Wszyscy, którzy uważają takie banalne zasady za pierdoły, niech zaczną
recenzować cudzy kod. Mi się to zdarza częściej niż pisanie własnego - i
spójność w tym przypadku ma pierwszorzędne znaczenie na szybkie
ogarnięcie danego kodu.
Co więcej, jak się okazuje po moich znajomych - wszyscy którzy nie mieli
takich standardów cierpieli z tego względu niemożebne katusze, musząc
zrecenzować/poprawić cudzy kod, w którym każdy pisał jak chciał i nie
wychodził poza swoją działkę.
Także, zgadzam się w 150% z A.L - i szczerze mówiąc, mam generalnie w
du..ie ewentualne psioczenie zespołu na takie "upierdliwości"; szkoda
czasu na dyskusje na ten temat z kimś, kto tego nie rozumie ;-)

Za to chętnie zobaczyłbym jakieś inne, ciekawe "programming standards" -
inspiracji nigdy za mało :)

--
wloochacz

do góry

On Thu, 14 Apr 2011 08:44:51 +0200, Paweł Kierski<n...@p...net>
wrote:
> Wydaje mi się, że również na polu "standaryzacji" trzeba
> zachować umiar i dopasować narzędzia do zastosowań. Np. nie
> widzę specjalnego sensu w standaryzowaniu pierdół w postaci
> "Stawiamy spację między 'if'

No dobra, ale mówiliśmy o fundamentalnych sprawach typu czy, kiedy i
jak stosować techniki obiektowe.

do góry

W dniu 2011-04-14 09:18, wloochacz pisze:
> W dniu 2011-04-14 08:44, Paweł Kierski pisze:
>> W dniu 2011-04-13 21:30, A.L. pisze:
>> [...]
>>> Niby dlaczego?... U mnie w firmie zawsze jest wiecej do srobienai niz
>>> "mocy przerobowych" co nie przeszkadza miec rozne dokumenty pod
>>> wspolna nazwa "programming standards" ktorych przestzreganie jest
>>> wymuszane w sposob drakonski, poczawszy od zautomatyzoanych narzedzi
>>> po manualne "code reviews". Dzieje sie tak, albowiem zauwazono (nie
>>> tylko w mojej firmie) ze "strata czasu" zwiazana z porzadnym
>>> kodowaniem jest znacznie mniejsza nis rzeczywista strata czasu
>>> znacznie pozniej, gdy przyjdzie modyfikowac program lub szukac bledow.
>>
>> Wydaje mi się, że również na polu "standaryzacji" trzeba zachować umiar
>> i dopasować narzędzia do zastosowań. Np. nie widzę specjalnego sensu
>> w standaryzowaniu pierdół w postaci "Stawiamy spację między 'if'
>> a nawiasem czy nie?". Choć już otwieranie bloków (nawias w tej samej
>> linii lub następnej) bywa istotne dla czytelności kodu przez większość
>> - wypada się zastanowić, czy warto wymuszać na ludziach, czy może
>> przygotować środowisko tak, żeby każdy pisał, jak chce, a automat
>> utrzymywał spójność w repozytorium.
>>
>> Po za tym - inaczej to będzie wyglądało w zespole kilkuosobowym,
>> a inaczej w projekcie tworzonym we współpracy kilkunastu takich
>> zespołów. Mniejsze projekty mogą sobie pozwolić na nieco większą
>> elastyczność.
> Nie zgadzam się z Tobą - ja mam mikry zespół składający się z kilku
> osób, ale mam też pewien dokument w którym w dość restrykcyjny sposób
> opisałem wszystkie takie jak je nazywasz - pierdoły.
> Zgodziłem się na jeden kompromis - wszystko to co opisałem, uzyskuję za
> pomocą automatycznego formatowania kodu wbudowanego w IDE.
> Nie było moim celem zmuszanie kogokolwiek do trzymania się pierdół,
> tylko do zachowania konwencji.
> Wszyscy, którzy uważają takie banalne zasady za pierdoły, niech zaczną
> recenzować cudzy kod. Mi się to zdarza częściej niż pisanie własnego - i
> spójność w tym przypadku ma pierwszorzędne znaczenie na szybkie
> ogarnięcie danego kodu.
> Co więcej, jak się okazuje po moich znajomych - wszyscy którzy nie mieli
> takich standardów cierpieli z tego względu niemożebne katusze, musząc
> zrecenzować/poprawić cudzy kod, w którym każdy pisał jak chciał i nie
> wychodził poza swoją działkę.
> Także, zgadzam się w 150% z A.L - i szczerze mówiąc, mam generalnie w
> du..ie ewentualne psioczenie zespołu na takie "upierdliwości"; szkoda
> czasu na dyskusje na ten temat z kimś, kto tego nie rozumie ;-)
>
> Za to chętnie zobaczyłbym jakieś inne, ciekawe "programming standards" -
> inspiracji nigdy za mało :)

Może źle sprecyzowałem. Dla mnie istotne jest nie trzymanie się
standardów dla trzymania się standardów, ale osiągnięcie celu, jakim
jest czytelność kodu wystarczająca dla wszystkich członków zespołu.
Jeśli w ramach zespołu nie ma problemu, żeby czytać kod z pewnymi
różnicami w formatowaniu, to nie ma sensu tych różnic eliminować. Jeśli
są problemy, to oczywiście spisujemy, a najlepiej automatyzujemy. Takie
ustalenia (i rozwiązania) mogą się oczywiście zmieniać - byle szybko
reagować na potrzeby.


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

do góry

W dniu 2011-04-14 09:38, Andrzej Jarzabek pisze:
> On Thu, 14 Apr 2011 08:44:51 +0200, Paweł Kierski<n...@p...net> wrote:
>> Wydaje mi się, że również na polu "standaryzacji" trzeba
>> zachować umiar i dopasować narzędzia do zastosowań. Np. nie
>> widzę specjalnego sensu w standaryzowaniu pierdół w postaci
>> "Stawiamy spację między 'if'
>
> No dobra, ale mówiliśmy o fundamentalnych sprawach typu czy, kiedy i jak
> stosować techniki obiektowe.

Techniki obiektowe też są tylko narzędziem. Celem jest zwykle taka
struktura, która jest czytelna, podatna na modyfikacje, a jednocześnie
stabilna jeśli chodzi o sposób współpracy między elementami. Na pewno
warto spisywać i stosować reguły, dzięki którym ten cel będzie prostszy
do osiągnięcia.

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

do góry