Re: Opis do OCL (OS/2)

Autor: Jarek Lis (lis_at_okapi.ict.pwr.wroc.pl)
Data: Thu 25 Apr 1996 - 21:12:20 MET DST


Gregorio Kus (Grego_at_RMnet.IT) wrote:
: A kto do jasnej ... powiedzial ze to musi byc C czy C++.
: Wrocmy do podstaw[...]
: 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)

Nie:
Efektywnosc wymaga jedynie istnienia instrukcji niskiego poziomu. Sproboj
np. zgasic bit w Pascalu Wirtha.
A przenaszalnosc prosi programistow zeby efektywnych instrukcji nie uzywali.

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

Pijesz do Pascala? IMHO, nie ma istotnej roznicy pomiedzy C (ANSI)
a Pascalem.

: 2. Efektywnosc? [...] Najczescie zalezy
: od 2 faktorow:
: I. Czas dotepu do urzadzen fizycznych (dyski itp)
: II. Uzyty ALGORYTM (a nie jego implementacja)

To sproboj laskawco napisac kompilator w Fortranie np. A byly takowe pisane.

: 3. Przenaszalnosc? [...] Niech ktos sprobuje
: przeniesc program w C napisany przy uzyciu M$ C i MFC na OWL Borlanda.

Teraz przeszedles do ++, a to odrebna para kaloszy. Zreszta po co przenosic
pomiedzy MFC a OWL ? Wyzwanie powinno raczej brzmiec:
Niech ktos sproboje przeniesc program pisany z uzyciem OWL na Linux'a.

: 1. Nieczytelnosc.
: Im "lepszy" programista tym bardziej nieczytelny staje sie program
: (bo stosuje wiecej trick'ow, ktore oszczedzaja 1 byte pamieci

Nie - to jest programista w etapie drugim. Juz potrafi zaastosowac.
W nastepnym etapie rozwoju programista sam ograniczy stosowanie
nieczytelnego kodu. Owszem - czasem trzeba, i wtedy milo jest miec
narzedzie, ktore potrafi to robic.

IMHO, obecny programista przede wszystkim oszczedza.... SWOJA prace.

Tak swoja droga - rozszerzenia ++ sprowadzaja niestety programy na droge
'write only'.

: Ogolnie - zasada brzmi: KOD ZRODLOWY PROGRAMU POWINIEN BYC CZYTELNY
: PRZEDEWSZYSTKIM DLA CZLOWIEKA, A DOPIERO POTEM DLA KOMPILATORA.

Jedno z podstawowych przykazan dobrego programisty.
 
: 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"

Eee. Odkad zrozumialem jak dzialaja wskazniki, i odkad zaczalem uzywac
kompilatorow ANSI C z wykrywaniem rozbieznosci typow wskaznikow,
przestalem miec klopoty. Borland C jest w stanie wykryc 95% bledow
programisty - tylko trzeba sobie wlaczyc wszystkie ostrzezenia.

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

Jakies przyklady? Jedna z najbardziej konsekwentnych skladni, a ze
skomplikowana? 'Powerfull' nie moze byc proste.

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

Tak swoja droga tez mnie ciekawi dlaczego C wygralo? Ani nie promowal
jej DoD, ani nie byla na poczatku specjalnie dobra/rozpowszechniona na
pecetach.

Widze tylko dwie mozliwosci:
1. C bylo jedyna rozsadna opcja na unixach,
2. Jak to zwykle, M$ wmowilo klientom, ze profesjonalny program powstaje w
   M$C

A teraz ogolnie:
  Twoja krytyka to raczej byla krytyka asemblerow, a nie C. Tudziez
krytyka pewnych stylow programowania, nie majacych wiele wspolnego
z ulubionym jezykiem.

C++ a wlasciwie jezyki obiektowe, oczywiscie przy wykorzystaniu nowych
mozliwosci, to juz jest zupelnie inna filozofia niz jezyki algorytmiczne.
Osobiscie nie lubie, ale chyba faktycznie do nowych zastosowan, takich
nastawionych na przetwarzanie danych sa lepsze.

W sumie dyskusja nasza jest nieco jalowa - rynek sie ustabilizowal,
i w ciagu najblizszych lat 70% bedzie stanowilo C++. A reszta to minimalne
nisze.

Tak swoja droga - nie widze wielkich roznic pomiedzy jezykami w klasie
'algorytmiczne', oraz pomiedzy jezykami w klasie 'obiektowe'.
To jest raczej kwestia podejscia programisty i jego paro letniego
doswiadczenia.

: sprobuj Virtual Pascal - wersja 1.0

Sproboj C++ - bedzie lepiej wygladalo przy szukaniu pracy jako programista.

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

Hm, czy w C++ kod bylby istotnie inny.
Tak swoja droga - ile do tych 250 linijek dochodzi kodu w bibliotekach?

Jaroslaw Lis



To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:42:55 MET DST