🚀 go-pugleaf

W dniu niedziela, 23 kwietnia 2017 09:36:16 UTC+2 użytkownik slawek napisał:
> On Sat, 22 Apr 2017 14:06:57 -0700 (PDT), godek.maciek@gmail.com 
> wrote:
> > > C. Bez C nie byłoby ani Uniksa, ani Windows, ani 
> 
> > Ale to jest "argument", przepraszam bardzo, 
> > za czym? (albo przeciwko czemu?)
> 
> Niuuu... chiba nieprzeciw uczeniu C ?! A może że może C jest 
> przydatne do czegoś konkretnego i tym różni się od niektórych innych 
> niezwykłych języków?!
> 
> Oczywiście są takie zadania które łatwiej zrobić w jakimś języku X 
> niż w C (C++, C#, ew. Javie będącej prawie-taka-jak-C). Ale łączny 
> trud opanowania X i rozwiązania problemu zwykle jest większy niż 
> wysiłek zrobienia tego w C. A do tego wszystko co potrzebne zwykle 
> już jest zrobione - ilość bibliotek do C jest już większa niż do 
> Fortranu. 
> 
> Z drugiej strony C może być bardzo nieodpowiednie dla pokolenia 
> hipsterów z syndromem niezałapania się na tworzenie historii. Skoro w 
> C wszystko jest... to co oni biedaczki będą robić? Napisać parser? W 
> C parsery pisali już ich dziadkowie. I nie tylko pisali, ale 
> napisali. W C jest po prostu brak wyzwań w rodzaju "czy to się da 
> zrobić".  Bo wiadomo że się da.

c jest jezykiem w ktorym pisze, (wł. buduje) sie program
ale zarazem w c nie tylko buduje sie program ale tez zarzadza pamięcią (ramem, defakto każdym bajtem*) jak rowniez zarzadza sie cyklami (lekko z grubsza ale defakto
tak)
jakis jezyk ktory pozwolil by wlasnie zupelnie 'odsunac' to zarzadzanie ramem (o cyklach to nie wiem) moglby sie ew troche przydac (chocby koncepcyjnie).. i nie mowie
to o 'jezykach wysokopoziomowych' (pojeciu lekko glupim/glupio uzywanym (przynajmniej niegdys nie wiem jak 
teraz) ) bo o ile pamietam w tych 'jezykach wysokopoziomowych' o ramie tez byla mowa, (tylko ew uzywalo sie go jakos czesciowo czy cos w tym stylu)
- tylko mowie o jezyko w ktorym ew wogole nie operowaloby sie pojeciem ramu (bo mysle ze mozna)

*(c owa dygresja) w c przynajmniej tak powinno byc i raczej tak jest,
1)wiadomoz e w c uzywa sie bibliotek i wtedy nie ma sie kontroli nad tym co dana libka wyrabia z ramem ale 
mozna zalozyc ze sa one napisane jako tako normalnie 
(przynajmniej jesli sa napisane w c ) wiec powiedzmy ze
czlowiek godzi sie na 'wspolprace' ;c
2) czy kompilator c wkompilowywuje jakies ukryte bajty
w ramach juz danej apki? w sumie tez mozna zalozyc ze 
nie (aczkolwiek chyba ciegle mam male braki z reverse engeeneringu bo tak naprawde chcialbym dokladnie moc 
powiedziec dla danej eeczki czy danej dllki - tyle bajtow zajmuja ciala skompilowanych funkcji, tyle bajtow zajmuje
data section, tyle zajmuje sekcja pustego ramu, tyle zajmuje header (i to samo dla obrazu apki w pamieci systemowej) - chyba da sie to sprawdzic swoja drogą jakas prostą apką (przynajmniej w wersji w pliku to mozna chyba spokojnie przeczytac z pol w PE ew jakims objdumpem, w wersji w ramie chyba mozna to sprawdzic w ollydebug ale nie wiem jak upewnic sie co do tej kompletnosci)
- chwilowo chyba nie mam jednak czasu o tym poczytac - choc to szybkie praktyczne sprawdzanie ile bajtow ma konkretna sekcja w dll'ce czy w exe by sie przydalo 
tak dla rozrywki - jak ktos wie jak to latwo sprawdzic moze podrzucic info