W dniu wtorek, 11 listopada 2014 10:43:39 UTC+1 użytkownik firr napisał:

> c jest bardzo abstrakcyjny,

nie zgodze sie. C stanowi lekka abstrakcje ponad maszynami von Neumannowskimi.
To ze masz takie rzeczy jak typy char, short, int i inne, ktore odpowiadaja
rejestrom maszynowym, pokazuje, w jak duzej mierze C jest zwiazany ze
specyficzna klasa maszyn obliczeniowych. To, ze masz wskazniki, pokazuje,
jak bardzo jest przywiazany do tablicowego modelu pamieci.

> co do owego scheme
> to ciagle ciezko mi ocenic, ale szczerze mowiac nie jestem przekonany tj nie wierze
tak jakby apriori ze problemy w scheme latwiej jest wyrazic/rozwiazac w scheme niz w
c (powazne problemy (wezmy na przyklad konkretne przykladowe problemy
> 1"napisanie dobrego raytracera z dobra optymalizacją" albo
> 2"napisanie dobrego podsystemu fizyki (zderzen itp) 2d/3d"
> tak naprawde musisz rozwiazac jakby poza językiem, czy to ze bedziesz przy tym
uzywac
> jakiegoś jezyka (mozna wstawic dowolny) cośkolwiek tu pomoże ?
> - pytanie jest poniekad otwarte bo pewnosci ze nie pomoze nie mam, ale nie wiem
jak (wiec to ze pomoze jest tylko hipotezą), sam z siebie jakos nic nie widze - na
oko wyglada po prostu na to ze te problemy musisz rozkminic i rozwiazac na
pozajęzykowym polu -- z drugiej
> strony tworzenie czegos takiego obejmuje nie tylko rozkminianie ale tez i
testowanie wiec jezyk i srodowisko mogloby miec pewne znaczenie
> (moze bardziej nawet srodowisko typu edytor niz sam jezyk)
>
> koniec konców po rozpykaniu tematu (albo odpadnieciu bo czasem jest to na tyle
czasochlonne ze mozna stracic motywacje) mozna to zaimplementowac i to jest chyba
mniejsza czesc problemu, ja moge to wtedy zrobic w c
> bo jest to elegancjkie, dosyc wydajne i dosyc łatwe

Ostatnio w ramach swojego projektu zajmuje sie kinematyka odwrotna.
Znalazlem metode, ktora opiera sie na dekompozycji macierzy wzgledem
wartosci osobliwych. Po poszperaniu w sieci udalo mi sie wyszukac
pakiet do obliczen numerycznych i symbolicznych dla Scheme'u.

Znalazlem w tym pakiecie odpowiednia funkcje, i okazalo sie, ze ma
ponad 400 linii. Byl przy niej komentarz (autorstwa Geralda Sussmana),
ze funkcja zostala przepisana z kodu jakiegos innego
systemu Lispowego, ktory z kolei byl przerobiona wersja algorytmu
napisanego w fortranie.

Ten kod jest dla mnie przykladem tego, jak nie nalezy pisac programow.
Napisal go Sussman -- jeden z moich najwiekszych autorytetow i wielki
propagator idei, ze programy powinny byc pisane przede wszystkim tak,
zeby dobrze sie je czytalo.

Wysoki stopien optymalizacji i czytelnosc programow to nie sa sprzeczne
cele. Wydaje mi sie, ze to raczej nasze techniki programowania sa
niedorozwiniete.

Moim zdaniem idealny program powinien stanowic zapis rozumowania,
ktory przeprowadza programista. Programista powinien wypisywac swoje
zalozenia i twierdzenia, ktore nastepnie kompilator moglby wykorzystywac
do optymalizacji kodu.

Na przyklad, programista powinien wklepac do programu to, czym jest macierz
i na czym polega mnozenie macierzy, i nastepnie okreslic, jake sa wlasnosci
poszczegolnych macierzy zdekomponowanych w oparciu o SVD, i ewentualnie
kilka twierdzen pomocniczych (np. tych, ktore posluzyly do stworzenia algorytmu
w fortranie), natomiast kompilator powinien wypluc optymalny algorytm
faktoryzujacy.

> > > - nie wiem czy chce w to wszystko wnikac, mam ciagle problem z czasem i
energią. to zo mnie teraz glownie interesuje to piksele (zwane przezemnie
programistycznym piachem)
> >
> > a udalo Ci sie w ostatnim czasie opracowac jakies nowe ciekawe rzeczy?
>
> narazie nie,

ja u siebie zauwazylem cos takiego, ze moj projekt przez wiekszosc czasu
stoi w miejscu, az w koncu cos we mnie dojrzeje i dokonam jakiegos przelomu
(i potem znow stoi w miejscu...)