Autor: Gregorio Kus (Grego_at_RMnet.IT)
Data: Thu 25 Apr 1996 - 20:34:00 MET DST
Poniewaz przejechalem sie juz po M$, po Netscape,
ostatnio odrobinke szarpnalem Intel'a, a wlasnie mam zamiar
przejechac sie po C/C++, wiec moze na poczatek (wybaczcie)
powiem dwa slowa n/t dlaczegoz tak sie czepiam:
1. Wcale nie jestem z natury przekorny
2. Nienawidze monopoli wszelkiego rodzaju
(dziwi mnie ze w kraju postkomunistycznym, po 50 latach doswiadczen,
nie mam wiecej zwolennikow w sprawie zwalczania monopolizmu)
3. Nie cierpie mo'd wszelkiego rodzaju (preferuje styl)
4. Uwazam masowy rynek informatyczny za zbyt mlody by potrafil sie
kierowac wlasnym rozumem. Samochod niemal kazdy potencjalny
uzytkownik potrafi sobie wybrac, oceniajac wlasne potrzeby/zasobnosc
kieszeni. Napewno nie jest tak w przypadku 95% potencjalnych uzytkownikow
komputera czy systemu operacyjnego
On Thu, 25 Apr 1996 11:58:23 +0200 Marek Sztukowski wrote:
> Ja tez posiadam srodowisko Emx wesja 0.9a i 0.9b z GCC
> Chetnie wymienil bym sie doswiadczeniami jezeli chodzi
> o programowanie pod OS2. Niestety ja dopiero zaczynam
> i mniej wiecej wiem co to jest C i C++ i czym sie roznia.
> ale poszukuje narzedzia do wizualnego tworzenia aplikacji
> PM pod OS2.
[...]
> To co moge powiedziec o tym to, to ze aby stwprzyc zwykle okienko
> pod PM wystarczy wpisac 4 (cztery!!!!!!!) linijki kodu pod C++
> Czy ktos ma do tego dokumentacje lub zna program do wizual. tworz.
> aplikacji ?. Prosze o kontakt.
[...]
A wiec do roboty!
A kto do jasnej ... powiedzial ze to musi byc C czy C++.
Wrocmy do podstaw:
ja do dzisiaj nie rozumiem zupelnie powodu dla ktorego wybuchla ta moda
na uzywanie tego cholernego polassemblera jakim jest C. Byl to jezyk
zaprojektowany z jasnym celem: napisania w nim PRZENOSNEGO systemu
operacyjnego. Zauwazmy, ze musial miec w zwiazku z tym dwie praktycznie
sprzeczne cechy:
1. Efektywnosc - a co za tym idzie (w czasach kiedy techniki automatycznej
optymalizacji byly w powijakach) musial byc jezykiem stosunkowo
niskiego poziomu
2. Przenaszalnosc - a co za tym idzie, musial byc jezykiem stosunkowo
wysokiego poziomu (aby uniezaleznic sie od architektury sprzetu)
Trzeba przyznac, ze stworzenie takiej "wewnetrznie sprzecznej" hybrydy
Kerninghamowi i Ritchiemu sie udal naprawde niezle. Powstal swietny jezyk
do... NO WLASNIE - DO ? do pisania systemow operacyjnych (i oprogramowania
systemowego)
Natomiast do pisania programow jakiegokolwiek innego rodzaju? Alez,
prosze Panstwa - toz to kompletny szajs.
Zalety:
1. Nieprawdopodobna elastycznosc?
No i co z tego ... asssembler jest jeszcze bardziej elastyczny.
Czy to jest powod do pisania w assemblerze?
Nie lepiej to pisac w PORZADNYM jezyku, o pieknej, eleganckiej
"matematycznie czystej" strukturze, a jedynie te pare fragmentow
(najwyzej 5% kodu normalnego programu) walnac w assemblerze?
2. Efektywnosc?
No i co z tego?
A) Assembler jest jeszcze bardziej efektywny
B) Czas wykonania ogromnej wiekszosc aplikacji w znikomym stopniu
zalezy od takich roznic jak umieszczanie czesciej uzywanych
zmiennych w rejestrach zamiast w pamieci. Najczescie zalezy
od 2 faktorow:
I. Czas dotepu do urzadzen fizycznych (dyski itp)
II. Uzyty ALGORYTM (a nie jego implementacja)
C) Dzis kompilatory optymalizujace potrafia niejednokrotnie lepiej
zoptymalizowac kod niz zrobi to przecietny programista.
3. Przenaszalnosc?
Przez dlugi, dlugi czas (czas interfejsow znakowych) prawie bez
trudu mozna bylo przenosic rownie latwo programy napisane w FORTRANIE,
Moduli czy Pascalu. Skonczylo sie wlasciwie wraz z upowszechnieniem
sie tych wszystkich GUI - od windoze, przez Unixowe X'y po WPS w OS/2.
Tylko, ze wraz z tym - skonczyla sie rowniez przenaszalnosc w C -
wazniejsze sa bowiem biblioteki niz jezyk. Niech ktos sprobuje
przeniesc program w C napisany przy uzyciu M$ C i MFC na OWL Borlanda.
i za te pseudo-zalety zaplacilismy (wszyscy, nawet przeciwnicy C, bo kiedy
wybuchla moda na C - nie sposob bylo znalez pracodawce, ktory by nie zapytal
potencjalnego pracownika-programisty: ALE W "C" TO PAN UMIE PROGRAMOWAC???)
cala masa potwornych wad tego cholernego scierwa. Nie sposob tu opisac
wszystkich, wiec napisze tylko o tych najbardziej rzucajacych sie w oczy
(czy raczej w mozg).
1. Nieczytelnosc.
Im "lepszy" programista tym bardziej nieczytelny staje sie program
(bo stosuje wiecej trick'ow, ktore oszczedzaja 1 byte pamieci
[lub wcale, bo mamy przeciez kompilatory optymalizujace],
czy 2 cykle zegarowe [lub wcale, bo mamy przeciez kompilatory
optymalizujace], czy wreszcie [przypadek najczestszy] - to co
niedoswiadczony programista napisze w trzech linijkach, doswiadczony
napisze w jednej [mimo iz czesto kompilator {optymalizujacy}
wygeneruje ten sam kod wynikowy - za to ta 1na linijka bedzie
kompletnie nieczytelna, a "C guru" nazwie to "elegancja kodu" ).
dlaczego tak wiele miejsca poswiecilem "czytelnosci" (czy nieczytelnosci)?
Otoz, JA moge miec lekkiego zajoba na punkcie oszczedzania 1byte'a
czy 2cykli zegarowych, bo ja pisalem powazne aplikacje na komputery
z 8080 / 2MHz i 8kB RAMu, wiec XRA A to byl obowiazek (zamiast MOV A,0)
ale mlodsi odemnie, chocby tylko o 5 lat, nie powinni juz wogole takimi
bzdurami zawracac sobiue glowy. Raz, ze moc obliczeniowa wspolczesnych
procesorow tudziez zasoby RAMu przecietnego komputera wzrosly
NIEPOMIERNIE, a dwa, ze kazdy inzynier-informatyk powinien wiedziec
iz koszt czasu zycia przecietnej aplikacji zalezy w najwyzej 30%
od pierwotnego kodowania - zas reszta wydawana jest na "maintenance",
i to wcale nie tylko ze wzgledu na buraki, ale rowniez ze wzgledu na
rozwuj/zmiane potrzeb/wymagan uzytkownika, zmiane standardow etc.
Ogolnie - zasada brzmi: KOD ZRODLOWY PROGRAMU POWINIEN BYC CZYTELNY
PRZEDEWSZYSTKIM DLA CZLOWIEKA, A DOPIERO POTEM DLA KOMPILATORA.
2. Slaba ochrona przed typowymi bledami programistycznymi (to zaplata
za elastycznosc C), przede wszystkim - slaba kontrola typow danych
i "arytmetyka na wskaznikach" bez ktorej w C nie da sie prawie nic
zrobic, a jest zrodlem 80% bledow programistycznych wogole i 99%
bledow z gatunku "najtrudniej wykrywalnych"
3. Potwornie skomplikowana i niekonsekwentna skladnia (ktora nazwac
musilabym kretynska, gdyby nie to, iz wiem dla jakich celow ten
jezyk powstal) ktora ogromnie utrudnia opanowanie tego jezyka.
Teraz, biorac to wszystko pod uwage, ktos moglby powiedziec - to znaczy
ze wszyscy programujacy w C to durnie a tylko jeden Kus jest madry?
Nie wcale tak nie mysle. To po prostu jak z windoze - w momencie jak
zdobylo sobie 90% rynku (z niezbyt zreszta zrozumialych powodow) bardzo
niewiele osob pisze dla innych srodowisk/systemo operacyjnych, gdyz
zwyczajnie ciagnie tam gdzie jest klientela. Kiedy wybuchla moda na C
(z poczatku byl to po prostu rodzaj snobizmu doswiadczonych programistow,
za nimi poszly cielaki - znac C bylo w dobrym tonie, kto nie znal C - nie
liczyl sie) nie sposob bylo znalezc pracodawce jesli nie chcialo sie
pracowac w C. (Mowie oczywiscie o prawdziwym programowaniu a nie o
clipperowaniu czy dBase'owaniu). Skonczylo sie tak, ze i ja popracowalem
sobie w C. I nigdy go nie polubialem. Ot, zlo konieczne, jakich w zyciu
wiele.
C++ - owszem, zmienil bardzo wiele. To nadal jest jednak "postfiksowo
inkrementowany C", do ktorego w sposob mniej czy bardziej sztuczny (bo
inaczej sie z tym scierwem u nogi nie dalo) Stroustrup wrzucil niektore
wynalazki ze Smalltalk'a. Z "matematyczna czystoscia" obiektowo-rozszerzonego
Pascala (bo na bazie "matematycznie pieknego" jezyka) jakim jest Delphi
nie ma sie nawet co porownywac.
Tak sie rozpisalem nad czescia ogolna, ze na szczegolowa nie starcza mi
juz ani czasu ani ochoty. W kazdym razie:
> ale poszukuje narzedzia do wizualnego tworzenia aplikacji
> PM pod OS2.
sprobuj Virtual Pascal - wersja 1.0
(full functional demo do sciagniecia z http://www.fprint.co.uk/vpascal)
[nie nalezy tracic czasu na bete z hobbesa]
Takie wizualne to to jeszcze nie jest, ale aplikacje PM w tym sie da
swietnie pisac [przyklad: w pelni funkcjonalny zegar analogowy PM,
"resizeable" etc - to zaledwie 250 linijek kodu] a kompatybilnosc
z BP7 i z Delphi jest nieomal doskonala.
Grego
-- /------------------------------------------------------------------ Gregorio Kus Grego_at_RMnet.it Grego_at_cyberspace.org ROMA, Italy http://www.RMnet.it/~grego Grego_at_FreeNet.hut.fi
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:42:55 MET DST