W dniu wtorek, 11 listopada 2014 01:48:52 UTC+1 użytkownik g...@g...com
napisał:
> W dniu poniedziałek, 10 listopada 2014 12:30:08 UTC+1 użytkownik firr napisał:
>
> > c nie jest zbyt jednorodny, ale z tego co powyzej to owo scheme tez nie wyglada
mi wcale na cos malego i jednorodnego; z tym liczeniem slow kluczowych to przesada w
c wiekszosc tych slow to nazwy typow (ktore tak naprawde mozna by uznac za typy
blibioteczne choc wbudowane),
> > reszta to glownie chyba 3 slowa if for i return
>
> no, jest jeszcze break, continue, goto, while, do, switch, case, default.
> ale zgoda, to nie jest najwazniejsze.
> scheme nie dostarcza takich rzeczy, jak for, while, do, switch czy return,
> ale dostarcza srodkow, w oparciu o ktore mozna sobie zdefiniowac takie
> wyrazenia, a takze wiele innych
>

te nie sa zbyt istotne, moze goto/break
(w sumie z tych slow kluczowych w c zostaja
ze dwa trzy ktore wlasnie jakby odpowiadają
opkodom minimalnego assemblera)


> zgoda, ze nie jest to calkowicie minimalistyczne. calkowicie minimalistyczny
> jest rachunek lambda, ale dla wielu zastosowan jest niepratyczny, dlatego
> warto go rozszerzyc przynajmniej o arytmetyke, ifa i wartosci boolowskie.
>
> ostatnio przerabiam ksiazke "Handbook of Practical Logic and
> Automated Reasoning" Johna Harrisona, ktory wprowadza w niej przyklady
> w jakims wariancie MLa (chyba Caml, ale moge sie mylic). Piszac implementacje
> roznych rachunkow logicznych, musi naprawde sporo miejsca poswiecic zagadnieniu
> parsowania, natomiast jezeli przyjmie sie konwencje stosowania "w pelni
> onawiasowanej notacji polskiej", sprawa staje sie trywialna (zas zysk
> wynikajacy ze wprowadzenia wlasnej smiesznej notacji jest zaden)
> [inna sprawa, ze ML ma naprawde fajny system typow, ktorego troche
> w Schemie brakuje]
>
> > - ilosc sluw kluczowych nie bardzo sie ma do architektury ducha jezyka ktora w
przypadku c jest mz bardzo skomplikowana - 'architektura ducha' scheme mi wyglada z
grubsza ani na wyraznie mniej skomplikowana ani na wyraznie bardziej, moge powiedziec
ze te niektore nieco bardziej skomplikowane wyrazenia te np gdzie wchodzi juz ta
lambda define i dalej nie wygladaja mi wcale za naturalnie
>
> Scheme jest duzo bardziej abstrakcyjny od C. Intencja stojaca za
> jezykiem C jest taka, zeby miec duza kontrole nad tym, co robi
> komputer. Intencja stojaca za Schemem jest zupelnie odwrotna
> -- przede wszystkim interesuje nas to, jak najlepiej opisac
> dany problem.
>

c jest bardzo abstrakcyjny, 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





> > - 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,