On 2012-01-27 19:09, Robert Zemła wrote:
> Przesadzasz :-) WinAPI nie jest złe a już na pewno nie jest niespójne.

Bzdura. WinAPI to wpływ wielu koncepcji posklejanych gumą do zucia
wliczając w to różne wartości true/false czy funkcje żywcem wyrwane z
posixa/unixa wstydliwie chowane w czeluściach msdn. Spójne? Może mam
różne definicje.

> Bywa czasem upierdliwe, wymaga użycia innych technik programowania i
> sporej wiedzy o systemie.

Programowanie wymagające sporej wiedzy o systemie to promil zagadnień.
Zazwyczaj dąży się aby wiedza o systemie była minimalna. Idealnie -
programy są niezależne od systemu. *Nawet* na mikrokontrolerach widać
taką tendencję.

> To są chyba główne powody dlaczego wielu go
> nie lubi.

Wielu nie lubi bo doskonale wie że można za darmo lepiej pod *każdym*
względem.

> No tak. Nie ważne jak, ważne że działa. Potem niech się ewentualnie
> martwi ten co po nim ten kod przejmie. Nie przekonasz mnie że
> programista nie musi mieć choćby minimum wiedzy komputerze.

I nie przekonuje. Przekonać jednak mogę że wiedza co to jest DWORD jest
*zbędnym* śmieciem wciskanym przez system operacyjny nie mającym żadnego
sensu w programowaniu ogólnym. Każdy rozsadnie napisany program
odizoluje typy WinAPI aby nie zanieczyszczały kodu. Qt jest takim
przykładem izolacji WinAPI od logiki kodu.

> Nie tylko Delphi, aczkolwiek pisząc to przypomniała mi się pewna
> sytuacja której byłem świadkiem. W wielkim skrócie człowiek nie był
> wstanie wdrożyć pewnej funkcji do programu bo komponent z którego
> korzystał nie oferował takiej funkcjonalności.

Piszesz o tym że jest wielu miernych programistów. No jest. I co z tego?
I co z tego że większość z nich programuje w onklikach w RADach?

> Zawsze można zrobić błąd. Jeżeli człowiek umie napisać kod
> wykorzystujący bezpośrednio WinAPI to z debugowaniem tym bardziej nie
> będzie mieć problemu.

Zaryzykuje że *NIGDY* nie pisałeś niczego większego, czyli przynajmniej
kilkanaście KLOCów w zespole. Nie trzeba mieć umiejętności programowania
WinAPI aby pisać wydajne, skomplikowane aplikacje. Gorzej: wydaje i
skomplikowane aplikacje nie biorą się z doskonałej wiedzy hakerskiej o
DWORD tylko z algorytmów, wzorców, technik przy których WinAPI jest na
poziomie głupawego, płaskiego interfejsu OS który tylko przeszkadza. Z
taki wlasnie płaskim, gównianym interfejsem namęczysz się kilka razy
więcej pisząc mały programik do odbierania znaków niż z byle-jakim
środowiskiem obiektowym.

>> Pomyliłeś programowanie obiektowe z RAD.
> Napisałeś "obiektowe środowiska".

Obiektowe środowiska to Qt, .NET, Java. Żadne z nich nie wymaga używania
RADów. Za to każde wymaga używania obiektów. Dostarczają kilka rzędów
wielkości więcej funkcjonalności niż WinAPI. W tym również taką jaką
zainteresowany jest autor wątku (łatwe thready, signal-slot, wrapowane
Comy).

> Natomiast nie widzę związku z brakiem
> możliwości połączenia programowania obiektowego i WinAPI

Oczywiście że nie widzisz. MS tez nie widział i powstalo g... o nazwie
MFC. Jesli masz zacięcie do archeologii to możesz dalej tego używać.
Pomogło dopiero solidne odizolowanie WinAPI od programisty aby mogły
powstać wygodne środowiska .NET. *SOLIDNA* izolacja od kretynizmów
WinAPI stoi u podstaw sukcesu C# - wszystko jest spójne bo wreszcie ktoś
to zaprojektował.

> Programuję w tym od lat, napisałem sporo różnych aplikacji, uzbierałem
> sobie pokaźną bibliotekę przeróżnych klas (do tego typu programów używam
> C++, dawniej MASM32), w związku z tym do pisania prostych (i brzydkich)
> programów nie potrzeba mi nic więcej.

Wpadleś w typową studnie potencjalu: to co mam jest wystarczające, a
więc jest najlepsze, nie ma sensu robić nic lepszego, przecież asm
wystarczy do wszystkiego. Porozgladaj się do okoła. Mozna napisać
program z tego wątku używają kilku linijek pod warunkiem użycia
wlaściwego narzedzia. Nie jest nim niskopoziomowy zestaw funkcji OS
jakiegoś systemu operacyjnego. To *najgorszy* wybór ze wszystkich
innych, nawet od Delphi.

> Podsumowując nie jestem wrogiem nowocześniejszych technik programowania,
> nie zgadzam się tylko że WinAPI jest złe i że programista nie musi znać
> się na tym co robi.

Trudno. Mamy inne punkty wyjścia do dyskusji. Przy czym ja nigdzie nie
pisałem o tym że programista ma się nie znać. Problem w tym, że jeśli
programista *naprawdę* dobrze się zna na programowaniu docenia inne
rzeczy niż hakerskie zagrywki z 30-letnim WinAPI (w tym roku mamy
jubileusz ogłoszenia Win1.0 a wiele funkcji pochodzi koncepcyjnie z
tamtych lat).

Staram się przekonać tylko autora, że WinAPI jest rozwiązaniem którego
nie powinien nawet kijem dotykać ponieważ *większośc* problemów
rozwiazuje mu .NET kilka razy mniejszym nakładem środków.