Re: Platforma NET Framework 1.1

Marek Janaszewski /USUN_TO. z adresu!/ wrote:
> dobroci. Coraz więcej kodu jest zarządzanego. Ale to będzie problem zawsze,
> np. jeśli jest dostępny obiekt COM albo usługa web, którą chce wywołać nie
> należy liczyć, że w językach niskiego poziomu jest możliwość łatwego
> wywołania. Z drugiej strony tworzenie wszystkie pod języki niskiego poziomu

W OS/2 cały niesamowicie mocny mechanizm obiektowości był
dostępny za pomocą prostego interfejsu napisanego w C i
dostępnego na przykłąd z poziomu skryptów REXX. Parę funkcji
obecnych w COM co prawda mu brakowało, ale jak widać -- da
się :)

Problemem COM IMHO jest to, że jest to cudowna techno-
logia, która jednak nie uwzględnia niezbędnej prostoty
realizacji i szybkości działania. Opłaca się ją stosować
do dużych obiektów i w językach bardzo wysokiego poziomu,
ale nie ma sensu dla małych kontrolek i w prostych języ-
kach typu C. Dla mnie to wada, ale na ten temat mogą być
odmienne poglądy.

> powoduje nienaturalność wywołania tego pod językami wysokiego poziomu. Stąd
> konieczność tworzenia owijek i pośrednich interfejsów. No jesteśmy w punkcie
> wyjścia jeśli te owijki dostarczają dodatkową funkcjonalność.

Wiele interfejsów niskiego poziomu bardzo ładnie się
"owija" w wysokim poziomie bez naddatku kodu i straty
wydajności. Taki interfejs jednak od początku musi być
pomyślany jako "czysty". Win32 API nie jest idealne, ale
nie jest wielkim problemem owinięcie go warstwą obiektową
nawet własnej produkcji, a do tego można go stosować bez-
pośrednio, jeśli komuś zależy na maksymalnej wydajności
fragmentu kodu.

Ja na przykład pisząc edytor kodu HTML samą kontrolkę
edycyjną z kolorowaniem składni napisałem jako DLL w
C z bespośrednim "wołaniem" Win32 API, zaś aplikacja
korzystająca z niej jest programem w C++ korzystającym
z obiektowej osnowy własnej produkcji.

> 1. Nie wszystko musi i może być wystawione jako Win32 API. Bariery zawsze
> występuje.

Ja bym to określił tak: musi być wystawione wszystko,
na czego bazie można budować wyższe mechanizmy. Nie może
być tak, że system udostępnia jakąś podstawową funkcję
przez interfejs obiektowy, ale nie przez prosty interfejs
C, uniemożliwiając w ten sposób np. szybkie i proste
wywołanie jej z miniaturowego programu pisanego w C.

> 3. Win32 API posiada specyfikę C i wcale nie jest uniwersalnym rozwiązaniem.

Jest uniwersalniejsze niż C++, Pascal czy cokolwiek
innego. Wspólnym denominatorem zawsze powinien być
kod maszynowy i jakaś prosta konwencja wywoływania
funkcji, a język C spełnia te warunki przez silne
związki z asemblerem i obsługę prostej konwencji.

> 4. Platforma może posiada własny kod. Jeśli komuś się to nie podoba niech
> napisze go dla platformy jaką chce.

I to jest chyba najlepsze podsumowanie. Chyba zacznę
się intensywniej uczyć GTK+ :)

> Pytanie czy to jest odpowiedni moment. Ja tego nie wiem. Myślę, że jest to
> ryzyko Microsoft. Przekonamy się w przyszłości czy miałeś racje wieszcząc
> klęskę .NET Framework.

Ja nie wieszczę klęski. Raczej wyrażam poważne obawy co do
tego, czy cały rynek systemów operacyjnych i języków
programowania idzie w dobrym kierunku. IMHO pisanie dobrych
programów _powinno_ być trudne, jeżeli jest to jedyny sposób,
by programy były maksymalnie efektywne i bezpieczne zarazem.
Przeciwny jestem upraszczaniu pracy programistów kosztem
szybkości wykonywania kodu.

Było już parę prób stworzenia procesorów wykonujących
bezpośrednio jakieś kodu języków średniego poziomu,
typu właśnie JAVA czy .NET, ale jak widać asembler
jest wciąż najważniejszy (bo w sumie jest jakimś tam
wirtualnym językiem, choć bardzo niskiego poziomu).
Uruchamiany przez system kod powinien zatem być bez-
pośrednio czystym kodem asemblerowym wygenerowanym
wprost przez kompilator, bez tłumaczenia go w czasie
uruchamiania lub działania.

Według mnie, jeżeli program nie jest w stanie działać
szybko na Pentium 100 z 64 MiB RAMu, to albo jest tak
specyficzny, że nie ma prawa działać (np. program
obliczeniowy, symulacyjny, zarządzający skomplikowanym
procesem technologicznych), albo - w przypadku oprogra-
mowania powszechnego użytku - został źle napisany.

Obowiązkiem programistów powinno być testowanie wydaj-
nościowe na sprzęcie sprzed kilku lat, wciąż często
używanym w wielu miejscach. Do tego takie testowanie
zapewni błyskawiczną pracę na współczesnych maszynach.

> Coś w tym musi być skoro nie istniała tylko Visual C++, ale był i
> VisualBasci, Delphi. Gdyby Visual C++ i Win32 API było takie cudowne i
> uniwersalne do tworzenia programów nie powstało by wiele alternatywnych
> rozwiązań.

IMHO przyczyną jest to, że za programowanie bierze się zbyt
dużo ludzi, którzy tego nie powinni robić. Delphi i VB są
świetnymi narzędziami do tworzenia własnych programów ograni-
czonego zasięgu (zamiast języków skryptowych), jednak skręca
mnie, jak widzę napisane w nich całkiem poważne aplikacje.
Oczywiście, zarówno Delphi i VB od swoich pierwszych dni
przeszły poważne zmiany i nie są już całkiem bezsensowne,
jednak IMHO to nie jest dobry kierunek rozwoju programowania.

-- 
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  mailto:Radoslaw.Sokol@polsl.pl        |
|                 |  http://www.grush.one.pl/              |
\................... ftp://ftp.grush.one.pl/ ............../