🚀 go-pugleaf

Janusz Stopa wrote:
>Wypada mi sie wtracic. Wiem, ze wiele osob na tej liscie uwielbia
>Fortran, czy inne jezyki bo maja w nich wiecej doswiadczenia.

Panie Januszu.

Tu sie Pan myli. Fortarnu bardzo nie lubie.
Nawet F90 choc to juz _zupelnie_ inny Fortran niz uzuwany
przeze mnie 4 czy 77.
I mam ku temu wydaje sie w miare obiektywne uzasadnienie.
Natomiast nie przeszkadza mi to docenic jednej z cech
Fortranu 90 jakim wlasnie jest obsluga macierzy.
Obsluga _calkiem_ rozniaca sie od tej z F4/77 ktora
byla nawiasem mowic koszmarna.
Po prostu fakty mowia za siebie czy sie je lubi czy nie.

Powiem moze ogolniej.
Uwazam ze jakakolwiek cecha jezyka o ktorej informacja
o jej charakterze i atrybutach jest tracona w czasie kompilacji
(a tak sie dzieje w przypadku tablic w C++) nie dorowna
w sensie mozliwosci optymalizacji i elastycznosci realizacji
tej samej cesze ale poprzez wbudowanie jej obslugi
w kompilator.

Bardzo lubialem i lubie natomiast Algol (mnowstwo kodu)
a szczegolnie Simule (chociaz w Simuli juz nie zdazylem
prawie nic powazniejszego napisac) i to wcale nei z powodu
doswiadczenia, ale z powodu latwosci i klarownosci
programowania i prawie zupelnego braku "efektow ubocznych".
Nigdy mi sie tej klarownosci nie udalo uzyskac w C++ mimo tez
kilkuletniego doswiadczenia, chociaz doceniam wszystkei
pozytywne cechy C++ czemu tez niejednokrotnie dawalem wyraz.
Najwieksze doswiadczenie mam wlasnie w C/C++ i mysle
ze nic zlego sie nie dzieje jesli krytycznie oceniam niewatpliwe
wady jezyka. Mnie osobiscie ich swiadomosc bardzo pomaga.

Wlasnie takie podejscie uwazam za sluszne i staram sie go
jedynie wyrazic.
Znac jezyk, jak najbardziej starac sie go lubiec (ja lubie C++:),
ale nie slepo, czyli znac jego wady, ale przy okazji nigdy nie
zasklepiac sie w jednym narzedzi/jezyku.
Patrzec w przyszlosc (np. Java, hm.. to raczej spojrzenei w bok)
ale tez w przeszlosc (np. Simula).
Mysle ze to jedyna ochrona przed popadnieciem w fanatyzm
i zatraceniem perspektywy w ocenie narzedzia/jezyka progr.

>Czy dany jezyk programowania jest "lepszy" od drugiego zalezy
>od wielu rzeczy, m.in. od upodoban dyskunatnow.

Tu przeciez (przynajmniej mnie) nei chodzi o to ktory jezyk
jest lepszy. Chodzilo wylacznei o konkretna ceche jezyka
ktora przeciez nie determinuje jego "lepszosci".

>Niemniej dyskusja
>(w tym i rownoleglych watkach) nie jest zbyt obiektywna. Mam wrazenie,
>ze wielu dyskunantow nigdy w zyciu nie widzialo powazniejszego projektu
>w przemsyle, ktory okazal sie byc wielkim sukcesem.

Zgadzam sie. Przyznaje sie ze nie widzaialem duzo duzych projektow
ale moze 3, 4 by sie znalazlo (patrzac z polskiej perspektywy oczywiscie) .
I to nie calkiem tak znow bez sukcesu.  ( -||- ).
A co najwaznejsze, te projekty byly tak bardzo praktyczne i dalekie
od conieco naukowej atmosfery panujacej niekiedy na p.c.o
ze az.. bolalo :).

>Nie jest prawda, ze TYLKO jezyk/kompilator pozwala na optymalna
>obsluge tablic (czy czegokolwiek innego). Akurat zamiarem C++
>jest umozliwienie pisanie szybkiego/optymalnego kodu:
>poprzez mozliwosc dolaczania specjalizowanych bibliotek (ktore
>tez moga byc napisane w C++) oraz bardzo niewielkiego narzutu
>w czasie wykonania danego programu. Owszem, pisanie w C++ wymaga
>doswiadczenia.

Ja nie twierdze ze C++ nie posiada _zadnych_ pozytywnych
sprawdzjacych sie w parktyce cech.
Tyle tylko ze te pozytywne cechy wcale nie wplywaja i nie czynia
lepsza np. obslugi tablic niz jest w rzeczywistosci.
Taka ekstrapolacja tracila by juz ideologia.

>> A jak inaczej je zrealizowac ?
>> Referencja to nie alias (przezwisko) ale rzeczywista zmienna przeciez.
>
>Chyba jednak nie tak. Na str. 97 "The C++ Programming Language" jest:
>"A reference is an alternative name for an object". A dalej w tekscie:
>"The obvious implementation of a reference is as a (constant) pointer
>... In some cases, the compiler can optimize away a reference ..."
>Proponuje uwaznie przeczytac.

Przeczytalem i nie jestem przekonany
Referencja to przeciez osobny typ.
Gdzie indziej wyraznie pisze:
"Poniewaz dla dowolnego typu T, _typy_ T i T& dopuszczaja
ten sam zbior wartosci inicjatora, wiec funkcje z _typami_
argumentow rozniacymi sie jedynie w tym zakresie nie moga
miec tej samej nazwy"
Zmienna referencyjna ma inny typ niz zmienna "niereferencyjna".
Dowodem jest jest inne zachowanie jako parametru funkcji
(mozna przekazac wartosc z powrotem, mimo ze sama
zmenna referencyjna (jak wszystko w C) jest przekazywana przez
wartosc. A wiec jednak nie jest to tylko alias (alternative name).
To osobny typ z wszelkimi tego konsekwenscjami.
Ja przynajmniej tak to rozumiem.
Zreszta co tu duzo mowic. Referencje sa wymienione
jako jedne z typow pochodnych w raporcie C++.
A przez co zrealizowane ?.
Tu sie poprawiam. Faktycznie niewazne i powiem wiecej,
niepowinno to wlasiwie nikogo obchodzic.

>Z wlasnego doswiadczenia moge powiedziec, ze robienie szumu
>wokol wskaznikow w C++ nie ma wiekszego sensu. Po prostu, jezeli
>program nie jest pisany przez swiezo przeszkolonych programistow,
>to problem ze wskaznikami w C++ nie istnieje.
>Sa natomiast inne problemy: np. z bledami w kompilatorach,
>watkami (threads), itd. ale to juz nie jest sprawa samego jezyka.

W duzej czesci sie zgadzam oczywiscie.

Pozdrawiam
--
Adam Karpierz
Poszukuje stalej pracy, moje dane:
http://www.adares.alpha.pl/cv.htm