W dniu 27-01-2012 20:35, Sebastian Biały pisze:
> 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.

Pokaż mi gdzie występują te różne wartości dla true/false. Wogóle gdzie
Ty tu widzisz POSIX'a??? Te czeluści MSDN to jedna z lepiej opracowanych
i ułożonych dokumentacji jakie widziałem.

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

Oczywiście że można wygodniej, ale nie koniecznie lepiej

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

Bo ideą Qt jest wieloplatformowość i przenoszalność. Tam nie ma miejsca
na niskopoziomowe API w żadnym systemie.

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

Nie koniecznie musi być miernym programistą. Brak mu podstaw żeby
rozwiązać samodzielnie problem na niższym poziomie. To nie nadmiar
wiedzy przeszkadza tylko jej brak.

>
>> 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 rozmawiamy tu o mnie i niech tak zostanie.

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.

Jak sam wcześniej zauważyłeś jest to niskopoziomowe API z przed 30 lat.
Sam się nie wiele rozwinął od tego czasu, rozwijają się za to
framweworki które się na nim opierają. Jeżeli komuś one nie wystarczają,
albo ma taki kaprys to niech sobie pisze w WinAPI.

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

Jeżeli nie masz doświadczenia to na pewno tak

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

No a cała ta funkcjonalność bierze się z WinAPI. Akurat do komunikacji z
peryferiami jak naprzykład COM nie ma nic lepszego od WinAPI. Czym
wogóle są łątwe wątki?

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

A co ma MFC do obiektowości??? Albo nie rozumiesz czym jest obiektowość
albo mnie podpuszczasz.

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

Nic nie stoi na przeszkodzie żebyś w C# pisał pod WinAPI. Sukces C#
wynika bardziej z sukcesu .NET no i usunięciu upierdliwości związanych z
zarządzaniem pamięcią na którą narzekałeś wcześniej.

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

Mylisz się. Używam narzędzi i technik adekwatnych do zadania. WinAPI nie
jest jedynym co znam.
Nawet na 8 bitowych mikrokontrolerach staram się unikać asm'a o ile to
możliwe.

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.

Można. W WinAPI myślisz że to zajmie więcej linijek?

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.

Zgadzam się, natomiast to czy WinAPI nie powinien dotykać kijem niech
sam oceni.

pozdrawiam