Forum » Programiranje » [Lisp] Ga kdo uporablja?
[Lisp] Ga kdo uporablja?
Temo vidijo: vsi
lobo_feroz ::
Čisto iz radovednosti me zanima, če ima kdo kaj več izkušenj z Lispom.
Sam sem se srečal z njim pred kratkim, ko sem začel uporabljati Emacs (le-tega uporabljam zaradi org-mode). Najprej se mi je nedomača sintaksa polna oklepajev zdela popolnoma nerazumljiva, potem pa sem se odločil, da si preberem vsaj nekaj osnov o jeziku.
Sedaj se nekaj malega igram s Common Lispom in prebiram simpatično knjigo Land of Lisp.
Lisp mi je zanimiv predvsem zaradi popolnoma drugačnih konceptov, kot sem jih bil pri programiranju navajen do sedaj. (Moje področje so namreč bolj embedded sistemi.) Trenutno sem sicer še čisto na začetku, ampak se imam namen naučiti vsaj osnove.
Kaj pa ostali? Kdo še uporablja Lisp?
Sam sem se srečal z njim pred kratkim, ko sem začel uporabljati Emacs (le-tega uporabljam zaradi org-mode). Najprej se mi je nedomača sintaksa polna oklepajev zdela popolnoma nerazumljiva, potem pa sem se odločil, da si preberem vsaj nekaj osnov o jeziku.
Sedaj se nekaj malega igram s Common Lispom in prebiram simpatično knjigo Land of Lisp.
Lisp mi je zanimiv predvsem zaradi popolnoma drugačnih konceptov, kot sem jih bil pri programiranju navajen do sedaj. (Moje področje so namreč bolj embedded sistemi.) Trenutno sem sicer še čisto na začetku, ampak se imam namen naučiti vsaj osnove.
Kaj pa ostali? Kdo še uporablja Lisp?
pegasus ::
Uporabljam ne, sem si pa že nekaj prebral o njem, tako kot o večini drugih programskih jezikov.
Baje da če razumeš lisp, so ti vsi drugi programski jeziki mala malca.
Pa še obligatory xkcd.
Baje da če razumeš lisp, so ti vsi drugi programski jeziki mala malca.
Pa še obligatory xkcd.
noraguta ::
Baje da če razumeš lisp, so ti vsi drugi programski jeziki mala malca.kdo to prav?
Pust' ot pobyedy k pobyedye vyedyot!
lobo_feroz ::
jype ::
Ja, Autodeskov softver ma vgrajen lisp, s katerim se da vse živo.
Lisp je močno orodje, ampak razumevanje konceptov mnogim dela preglavice in težko razmišljajo v njegovem kontekstu. Zelo relevantna je pripomba o kladivu in tem da vse zgleda kot žebelj.
Lisp je močno orodje, ampak razumevanje konceptov mnogim dela preglavice in težko razmišljajo v njegovem kontekstu. Zelo relevantna je pripomba o kladivu in tem da vse zgleda kot žebelj.
Spura ::
Ne vem ce je lisp ravno kladivo. Je bolj en zajeban svicarski noz. Jst sm sicer malo delal v Clojure-ju, ki je tip LISPa. Pol sem nehal, ker ima clojure slabe performancne karakteristike (ranga Python) in se tut ne bo kaj dosti to izboljsalo, ker ima immutability povsod.
Brane22 ::
jaz sem se zezal s schemo, ker sem se pač moral. Še zdaj mi ni jasno, kaj naj bi blo tko kul u nenehnem jebanju z oklepaji.
pegasus ::
Mogoče kot zanimivost - yahoo se je začel v lispu, danes že obstaja kar lepa zbirka lisp projektov za web.
jype ::
Če uporabljaš lisp, potem se je vredno potrudit (skoraj) vse probleme prevest na nekaj, kar se da rešit z najmočnejšimi lastnostmi lispa. DSLji in makri.
Zgodovina sprememb…
- spremenilo: jype ()
bleem ::
lisp sem uporabljal izključno za namene autocada ... še preden se se kaj bolj poglobil v programiranje nasploh ... takrat mi je delal preglavic še pa še ... :)
sherman ::
jaz sem se zezal s schemo, ker sem se pač moral. Še zdaj mi ni jasno, kaj naj bi blo tko kul u nenehnem jebanju z oklepaji.
Ugovor na sintakso programskega jezika je bolj na nivoju ugovarjati da motorna zaga grdo izgleda. Seveda, ce je take oblike da se ne da uporabit za zaganje je problem, sicer pa je ugovor zgresen. Oklepaji po mojih izkusnjah sploh niso problem, ce uporabljas spodoben urejevalnik, ki je emacs.
Okoli lispa je pa izgleda cel kup cudnih mitov in kultov. Seveda, ce je tvoj doseg python, ruby in nodejs potem se mogoce zdi da je nekaj posebnega, a dan danasnji ni.
Elisp je pa po vrhu se star in nekonsisenten. V emacs 24 smo recimo sele dobili lexical scope. Vseeno je emacs z elispom se vedno dosti bolj prijazen od vseh drugih konfiguracijskih jezikov, ki sem jih videl, kar pa res ni pretirano velika mnozica ;).
noraguta ::
zdej a govorimo o S izrazih a o lispu?
prvo kot prvo. s izrazi so nekak zelo dobra tekstualna reprezentacija astja(abstraktega sintaktičnega drevesa).
kar ima svoje dobre in slabe strani. prvo kot prvo trivijalno prepoznavanje oz parsanje in transformacija,
drugo kot drugo deluje le na S izrazih. programbilna tabela pa je tudi omejena le znjimi.
če hočete v lispu implementirat karkoli drugega rabite nov parser in novo izvedbo tabele oz sintaktičnega drevesa.
neko sanje o DSLjih je odveč. lisp je postavil zgolj okvirne koncepte nikoli pa niso bili njem implementirani.
makri pomagajo pri tako omejeni sintaksi skrajšati izrazno pot. vendar je to še vedno daleč od kakega sqla oz vljkučitvi letega v jezik.
pustimo ob strani da je za CL higiena makrov nepomembna in onemogoča elegantno implementacijo.
se pa da pav lepo predelovat kakšne DOM-e v lispu. Lep primer tega je bil PLT Scheme(dandanes racket). K je eden redkih jezikov kateri je omogočal neko mero "intentional" programiranja.
dejansko si samo gui formo vklučil in videl v editorju kjer si kofal kodo. Ampak je šlo za strogo linearno definirano drevo.
Lisp ima neke vrste vrdnost(predvsem zgodovinsko). Ampak pri dandanašnjih orodjih je precej preživeta zadeva.
nevem pa zakaj vrli administratorji ne brišejo postov like:
ker prekleti trap očigledno ni nikol povohal lispa ne makrov od blizu.
sintaksa omogoča človeku prijazno memoizacijo. like če si zapomniš 485859340 po postopku 48-58-93-40. naš kartkoročni spomin je omejen stem pa tudi izrazna zmožnost. memoizacija v lexerju parserju pa je dosti bolj raztegljiva, ni pa vse mogočna.
prvo kot prvo. s izrazi so nekak zelo dobra tekstualna reprezentacija astja(abstraktega sintaktičnega drevesa).
kar ima svoje dobre in slabe strani. prvo kot prvo trivijalno prepoznavanje oz parsanje in transformacija,
drugo kot drugo deluje le na S izrazih. programbilna tabela pa je tudi omejena le znjimi.
če hočete v lispu implementirat karkoli drugega rabite nov parser in novo izvedbo tabele oz sintaktičnega drevesa.
neko sanje o DSLjih je odveč. lisp je postavil zgolj okvirne koncepte nikoli pa niso bili njem implementirani.
makri pomagajo pri tako omejeni sintaksi skrajšati izrazno pot. vendar je to še vedno daleč od kakega sqla oz vljkučitvi letega v jezik.
pustimo ob strani da je za CL higiena makrov nepomembna in onemogoča elegantno implementacijo.
se pa da pav lepo predelovat kakšne DOM-e v lispu. Lep primer tega je bil PLT Scheme(dandanes racket). K je eden redkih jezikov kateri je omogočal neko mero "intentional" programiranja.
dejansko si samo gui formo vklučil in videl v editorju kjer si kofal kodo. Ampak je šlo za strogo linearno definirano drevo.
Lisp ima neke vrste vrdnost(predvsem zgodovinsko). Ampak pri dandanašnjih orodjih je precej preživeta zadeva.
nevem pa zakaj vrli administratorji ne brišejo postov like:
Če uporabljaš lisp, potem se je vredno potrudit (skoraj) vse probleme prevest na nekaj, kar se da rešit z najmočnejšimi lastnostmi lispa. DSLji in makri.
ker prekleti trap očigledno ni nikol povohal lispa ne makrov od blizu.
Ugovor na sintakso programskega jezika je bolj na nivoju ugovarjati da motorna zaga grdo izgleda. Seveda, ce je take oblike da se ne da uporabit za zaganje je problem, sicer pa je ugovor zgresen. Oklepaji po mojih izkusnjah sploh niso problem, ce uporabljas spodoben urejevalnik, ki je emacs.
sintaksa omogoča človeku prijazno memoizacijo. like če si zapomniš 485859340 po postopku 48-58-93-40. naš kartkoročni spomin je omejen stem pa tudi izrazna zmožnost. memoizacija v lexerju parserju pa je dosti bolj raztegljiva, ni pa vse mogočna.
Pust' ot pobyedy k pobyedye vyedyot!
lobo_feroz ::
Okoli lispa je pa izgleda cel kup cudnih mitov in kultov. Seveda, ce je tvoj doseg python, ruby in nodejs potem se mogoce zdi da je nekaj posebnega, a dan danasnji ni.
Kateri pa so po tvojem mnenju jeziki, ki omogočajo to, kar omogoča Lisp? In zakaj so boljši? Moje programerske izkušnje so večinoma v C-ju in assemblerju, tako da težko primerjam.
Brane22 ::
Ugovor na sintakso programskega jezika je bolj na nivoju ugovarjati da motorna zaga grdo izgleda. Seveda, ce je take oblike da se ne da uporabit za zaganje je problem, sicer pa je ugovor zgresen. Oklepaji po mojih izkusnjah sploh niso problem, ce uporabljas spodoben urejevalnik, ki je emacs.
Prej obratno. Naravni jezik stroja je strojni. Njemu najbližji praktični jezik, ki ponuja določeno abstrakcijo ob nezadušeni moči stroja je zame C/C++. Ta se je pokazal toliko, da je danes delovni konj večine industrije. Za vse ostalo bi moral imeti _zelo_ dober razlog za prehod na novi jezik.
Se pravi, novi jezik bi moral biti za novi namen ne samo boljši ampak toliko boljši, da mi prinese nazaj ves izgubljeni čas pa še kaj zraven.
To pa še nisem doživel.
noraguta ::
Se pravi, novi jezik bi moral biti za novi namen ne samo boljši ampak toliko boljši, da mi prinese nazaj ves izgubljeni čas pa še kaj zraven.
večina sodobnega lispa bazira na matematiki(lambda račun) ne na strojnih osnovah, scheme R6 specifikacija recimo zahteva še arbitrary precision aritmetiko(nekaj kar je v matemetiki povsem običajno). podobno kt večina sodobnih jezikov zaradi prenosljivosti bazira na virtualkah zavoljo prenosljivosti.
tko da imajo svoj namen, nenazadnje pa ne gre pozabit da same osnove lispa datirajo pred kakeršen koli c. c++ pa itak ni jezik ampak je skrpucalo.
Pust' ot pobyedy k pobyedye vyedyot!
Brane22 ::
En od primerov - gEDA.
preprost schematic. Skorajda vse napisano v C-ju, le za najvišji del je tp prišel na "genijalno" idejo, da to pa mora biti v Schemi, ker da bo tako omogočil enostavno dograjevanje programa.
Rezultat:
- leta zajebancij in praktično nikakršnega napredka programa
- čeprav je CAD na Linuxu vedno zanimiva tema, se z jebeno gEDAo resno ukvarjajo trije tipi
- stvar na modernih strojih ne dosega nivoja, ki ga je imel legendarni Tango, ki je laufal v 16-bitnem načinu na DOS-u na 50-200MHz ropotuljicah tipa 486 in Pentium. Tango so jasno pisali "analfabeti" v Cju in mogoče kaj v assemblerju.
Tudi nafta smrdi ampak za transport jo rabiš. Če si dišečo smrekico zmontiraš na špegu med vožnjo, še ne pomeni, da se voziš brez nje.
preprost schematic. Skorajda vse napisano v C-ju, le za najvišji del je tp prišel na "genijalno" idejo, da to pa mora biti v Schemi, ker da bo tako omogočil enostavno dograjevanje programa.
Rezultat:
- leta zajebancij in praktično nikakršnega napredka programa
- čeprav je CAD na Linuxu vedno zanimiva tema, se z jebeno gEDAo resno ukvarjajo trije tipi
- stvar na modernih strojih ne dosega nivoja, ki ga je imel legendarni Tango, ki je laufal v 16-bitnem načinu na DOS-u na 50-200MHz ropotuljicah tipa 486 in Pentium. Tango so jasno pisali "analfabeti" v Cju in mogoče kaj v assemblerju.
tko da imajo svoj namen, nenazadnje pa ne gre pozabit da same osnove lispa datirajo pred kakeršen koli c. c++ pa itak ni jezik ampak je skrpucalo.
Tudi nafta smrdi ampak za transport jo rabiš. Če si dišečo smrekico zmontiraš na špegu med vožnjo, še ne pomeni, da se voziš brez nje.
Zgodovina sprememb…
- spremenilo: Brane22 ()
noraguta ::
En od primerov - gEDA.
preprost schematic. Skorajda vse napisano v C-ju, le za najvišji del je tp prišel na "genijalno" idejo, da to pa mora biti v Schemi, ker da bo tako omogočil enostavno dograjevanje programa.
Rezultat:
- leta zajebancij in praktično nikakršnega napredka programa
- čeprav je CAD na Linuxu vedno zanimiva tema, se z jebeno gEDAo resno ukvarjajo trije tipi
- stvar na modernih strojih ne dosega nivoja, ki ga je imel legendarni Tango, ki je laufal v 16-bitnem načinu na DOS-u na 50-200MHz ropotuljicah tipa 486 in Pentium. Tango so jasno pisali "analfabeti" v Cju in mogoče kaj v assemblerju.
tko da imajo svoj namen, nenazadnje pa ne gre pozabit da same osnove lispa datirajo pred kakeršen koli c. c++ pa itak ni jezik ampak je skrpucalo.
Tudi nafta smrdi ampak za transport jo rabiš. Če si dišečo smrekico zmontiraš na špegu med vožnjo, še ne pomeni, da se voziš brez nje.
nikjer se nisem izkazal kot ortodoksen zagovornik lispa, ampak slabe implenemtacije ne zavržejo njegovega pomena.niti njegove uprabnosti. če se je geda zgedovala po emacsu in autocadu glede tega kako unificirat skripte in dato, to samo po sebi ni nič slabega. Če pa šepa implementacija je pa druga reč. (zakaj stvar ne dela kot mora je spet lahko trivialno ali pa za knjigo šlamparij, od tail optimizationov, tipizacije, do tega da se stvar sesuva) Ampak teh primerov je v industriji koliko? deset na šesto ali pa deset na deveto.
So pa druge stvari katere je lisp dal. Ponavaljanje patternov v objektnih jezikih postaja je naravnost trapasto. za praktično identično zdadevo o kateri je knuth pisu 30 let nazaj(literate programing) se pišejo biblioteke. Ampak z makri in spodobnim parserjem je to danes "trivialno" rešljivo.
pa še enkrat sem prav hud privrženev cja za nadgradnjo pa prisilne modularizacije, pa naj gre za objektno ali funkcijsko. hudo na živce mi gre pa multiparadigm c++ kateri štuka preoblečeno strojno kodo na slabo sintakso in slab metasistem.
o gedi in tangu pa še to, vedno se kje uporablja kaj sklofano za dos ker je preprosto učinkovito in za svoje potrebe zadovoljivo.
glede smrekce pa vsaj ne smrdi ti več, jasn pa da se voziš tistim kar maš. Itak je tema malo avantgardna.Maš pa s svojim pluvanjem po svoje tudi prav.Ampak vrednost lispa je prej v konceptih, kot neki vsesplošni uporabnosti. Tu pa tudi ni nič narobe če si kdo razšiti obzorje.
Pust' ot pobyedy k pobyedye vyedyot!
jype ::
Saj ko boš kdaj dejansko programiral ti ne bo treba več toliko filozofirat in boš lahko napisal tudi kaj praktičnega o lispu, ki je zastarel samo v glavah tistih, ki ga še ne razumete.
noraguta ::
Saj ko boš kdaj dejansko programiral ti ne bo treba več toliko filozofirat in boš lahko napisal tudi kaj praktičnega o lispu, ki je zastarel samo v glavah tistih, ki ga še ne razumete.
u multistage programiranju mislim da mam precej več pojma kot ti. pa kar nekaj kode katera dela. vsaj recimo korekto emitanje debuging v nemerletu je kar moja zasluga. pa racimo pre clr podpora(zgolj na sintaktičem nivoju) ampak type safe ravno tako. tko da odjebi sine. pa gre za statično tipiziran jezik kjer je precej več računovodstva s tipi kot pri lispu kjer je tipizacija dinamična makri pa nehigienični. zdej pa hitr na irc moderatorjem fafat. pezde
Pust' ot pobyedy k pobyedye vyedyot!
Zgodovina sprememb…
- spremenilo: noraguta ()
sherman ::
sintaksa omogoča človeku prijazno memoizacijo. like če si zapomniš 485859340 po postopku 48-58-93-40. naš kartkoročni spomin je omejen stem pa tudi izrazna zmožnost. memoizacija v lexerju parserju pa je dosti bolj raztegljiva, ni pa vse mogočna.
Ne vem ce si z namenom naredil napako pri stevilki ali ne :) a z napisanim se strinjam in to sem nekako hotel povedati, a izgleda da neuspesno. Moj ugovor je na to, da je sintaksa ponavadi najmanjsi problem in najlazje resljiv.
Kateri pa so po tvojem mnenju jeziki, ki omogočajo to, kar omogoča Lisp? In zakaj so boljši? Moje programerske izkušnje so večinoma v C-ju in assemblerju, tako da težko primerjam.
Kaj tocno pa po tvojem "omogoca lisp"? In kaj mislis z lisp, ker "lisp" ni tocno definirana stvar.
Se pravi, novi jezik bi moral biti za novi namen ne samo boljši ampak toliko boljši, da mi prinese nazaj ves izgubljeni čas pa še kaj zraven.
To pa še nisem doživel.
Poskusi pisat dokazovalne pomocnike ali kaj podobnega, kar zahteva resno manipulacijo netrivialne sintakse v C-ju, recimo. Saj ne da so unitipizirani lispi zelo primerni za to nalogo.
lobo_feroz ::
Kaj tocno pa po tvojem "omogoca lisp"?
Še ne vem, se šele učim.
Zaenkrat se mi zdi že obravnava funckcij kot prvorazrednih objektov zanimiva. Ali pa to, da je sama koda tudi podatkovna struktura, kar pride najbrž prav, če se igraš naprimer z genetskim programiranjem.Ampak seveda je normalno, da se mi zdi Lisp nekaj posebnega, ko pa sicer programiram v C-ju in Assemblerju. Kot si napisal:
Seveda, ce je tvoj doseg python, ruby in nodejs potem se mogoce zdi da je nekaj posebnega, a dan danasnji ni.
Zato me zanima, kateri so ti sodobni programski jeziki, ki si jih imel v mislih, in v primerjavi s katerimi ni Lisp nič posebnega. Ali so po tvojem od Lispa boljši in zakaj?
Moj glavni namen z Lispom je pridobiti si tisti del znanja programiranja, ki mi kot elektrotehniku manjka. Torej "višji" jeziki. Kmalu se bom začel učiti Python, ker ga potrebujem za službo, pa tudi sicer me zanima. Ker ne bi rad pisal v Python-u, razmišljal pa še vedno v C-ju, bi rad s pomočjo Lispa okusil različne pristope k programiranju.
Za ta namen se mi zdi zanimivo gradivo Structure and Interpretation of Computer Programs. Scheme, ki se v gradivu uporablja, pa je po mojem prvem vtisu s svojim minimalizmom idealen za ta namen.
Če mi bo znanje Lispa prišlo prav še v praksi, pa četudi samo za kakšno prilagoditev Emacsa, pa še toliko bolje.
In kaj mislis z lisp, ker "lisp" ni tocno definirana stvar.
Vem, ampak sem dobil vtis, da imajo različni dialekti kljub razlikam podoben pristop in omogočajo podobne stvari. Za Elisp pa vem, da je precej okrnjen.
jan_g ::
večina sodobnega lispa bazira na matematiki(lambda račun) ne na strojnih osnovah,
Meni so ravno zaradi lambda calculusa vsi jeziki, ki bazirajo na njem, zelo všeč, ker je to izjemno ekspresiven model. Se pravi, funkcije operirajo na funkcijah in vračajo funkcije. Recimo en feature, ki ga je posvojilo mnogo modernejših jezikov, je closure. Jaz mislim, da nam je lisp dal dosti dobrega.
Priznam pa, da kar se tiče dela v podjetjih, še nikoli nisem imel priložnosti delati z lispom (se pravi, da je zame bolj kot ne hobi). Kar je škoda, ampak kaj čmo. Sem pa delal z erlangom, ki je vzel določene aspekte iz družine prolog jezikov in to je tudi eno precej zanimivo področje. Mislim, da bi si vsak programer moral enkrat malo pogledati en jezik in družine lisp jezikov in enega iz družine prolog jezikov.
Brane22 ::
Meni so ravno zaradi lambda calculusa vsi jeziki, ki bazirajo na njem, zelo všeč, ker je to izjemno ekspresiven model. Se pravi, funkcije operirajo na funkcijah in vračajo funkcije. Recimo en feature, ki ga je posvojilo mnogo modernejših jezikov, je closure. Jaz mislim, da nam je lisp dal dosti dobrega.
Ampak to je "Fata Morgana" - lepo zgleda, ampak v realnem svetu ne obstaja. Funkcije ne morejo dejanjsko na nobenem pametnem OS kar tako spreminjati funkcij. Funkcije so izvršljiva koda in ta je v txt segmentu, ki je normalno read-only. Tudi če omogočiš vpis, se moderni CPUji ne odzivajo pretirano dobro na vpis v področje, ki ga imajo mogoče že v instrukcijskem cacheu.
Se pravi, gre za privid, ki ga potem nek program bolj ali manj pametno mapira v realni svet. Kaj imaš od tega ?
Vse kar meso podpira, je jmp in call. Pa še slednji je včasih preveč in se skok v subrutino opravi kar z jmp, če je lokacija skoka vedno ista n vnaprej znana.
Zgodovina sprememb…
- spremenilo: Brane22 ()
jan_g ::
Ne gre se za to, da funkcije spreminjajo funkcije, temveč da 'računaš' s funkcijami. Npr. v lambda calculusu x ni x (neko število), temveč id(x) (identita), katere pravilo je id(x) = x. Zaradi poenostavljenega zapisovanja se potem to preslikavo izpušča oz. se implicitno predpostavlja, da je x funkcija identitete. Torej moraš že v osnovi razmišljati drugače kot pri imperativnem programiranju. No, recimo, da za določene funkcije želiš, da se izvedejo zgolj enkrat. Pri običajnem imperativnem programiranju imaš globalne spremenljivke ali pa singleton classe za te namene. Tukaj pa definiraš funkcijo, ki matematično zgleda zelo preprosto, npr.: f(x) = once(f(x)). Ko boš torej želel, da se f(x) izvede zgolj enkrat, jo boš klical s pomočjo once() funkcije. Vsebina te funkcije ni pomembna (mimogrede, je zelo preprosta zaradi že prej omenjenih closure-jev), gre se za to, da imaš lep model tvojega programa, izražen s funkcijami. Lep za branje (v glavi si je imho lažje ustvariti sliko programa s pomočjo funkcij kot pa pri imperativnem programiranju z velikim številom spremenljivk, definiranih na različnih koncih), lep za debugging, lep za strojno parsanje, in tako dalje. Ne gre se zato, da lahko na tak način izraziš več kot s Turingovim strojem. Kako le, saj sta lambda calculus in turingov stroj ekvivalentna. Še tko, mimogrede, takim funkcijam kot je opisana (once) se reče fixed-point combinators in so izjemno uporabne pri takem načinu programiranja.
Ni nobenega privida, zgolj matematika. Zakaj je to koristno? Zato, ker je možno na tak način izraziti precej kompleksne operacije na eleganten in razumljiv način (za vse, ki jim je matematika blizu).
Ni nobenega privida, zgolj matematika. Zakaj je to koristno? Zato, ker je možno na tak način izraziti precej kompleksne operacije na eleganten in razumljiv način (za vse, ki jim je matematika blizu).
Zgodovina sprememb…
- spremenil: jan_g ()
Brane22 ::
Ampak CPu je podlaga vsega. In ta podlaga izvaja stvari klasično.
Se pravi, če potrebuješ neko transformacijo svoje kode v dejanjski program in je ta transformacija netrivialna, imaš problem.
Izvesti jo mora nek mehanizem, rezultat pa ne bo vedno optimalen.
In kaj ti sploh ta zadeva dejanjsko na koncu prišpara ?
Pišeš enkrat. Izvajaš praviloma _mnogo_ krat. In dostikrat tudi v mnogo instancah.
Vsako šparanje na enem koncu - pri pisanju, se ti tako praviloma pozna mnogokrat.
Se pravi, če potrebuješ neko transformacijo svoje kode v dejanjski program in je ta transformacija netrivialna, imaš problem.
Izvesti jo mora nek mehanizem, rezultat pa ne bo vedno optimalen.
In kaj ti sploh ta zadeva dejanjsko na koncu prišpara ?
Ni nobenega privida, zgolj matematika. Zakaj je to koristno? Zato, ker je možno na tak način izraziti precej kompleksne operacije na eleganten in razumljiv način (za vse, ki jim je matematika blizu).
Pišeš enkrat. Izvajaš praviloma _mnogo_ krat. In dostikrat tudi v mnogo instancah.
Vsako šparanje na enem koncu - pri pisanju, se ti tako praviloma pozna mnogokrat.
Zgodovina sprememb…
- spremenilo: Brane22 ()
Brane22 ::
In BTW, kje ti ta primer enkrat klicane funkcije lahko prav pride ?
Cela fora funkcije je vloga paketa kode, ki ga lahko večkrat kličeš z različnih lokacij.
Funkcija, ki jo kličeš samo enkrat se zdi nonsens. Pač izvedeš tisto kodo linearno brez klica funkcije. Če obstaja možnost,d a greš skozi to področje večkrat, pač uporabiš pogojno izvajanje s flagom, ki ga setiraš ob prvi izvedbi.
Kaj tako veliko ti prinese tu ta abstrakcija ?
Cela fora funkcije je vloga paketa kode, ki ga lahko večkrat kličeš z različnih lokacij.
Funkcija, ki jo kličeš samo enkrat se zdi nonsens. Pač izvedeš tisto kodo linearno brez klica funkcije. Če obstaja možnost,d a greš skozi to področje večkrat, pač uporabiš pogojno izvajanje s flagom, ki ga setiraš ob prvi izvedbi.
Kaj tako veliko ti prinese tu ta abstrakcija ?
jan_g ::
Obstajajo opravila, za katera želiš, da se izvedejo samo enkrat (oz. končnokrat) ne glede na to, kolikokrat jih invoka klicatelj, ne pa poljubno mnogokrat. V vsakem netrivialnem programu, kjer dela več ljudi, si v situaciji, ko ne moreš vplivati na to, kako drugi ravnajo s tvojo kodo - pri libih, ki jih daš v javnost, pa sploh. Inicializacije, zaseganje resourcov, itd. Meni taka abstrakcija prinese mnogo, ne trdim pa, da je funkcijsko programiranje idealna rešitev za vse probleme in za vsakega programerja.
jernejl ::
In kaj ti sploh ta zadeva dejanjsko na koncu prišpara ?
Manj LOC (večja izrazna moč), krajši čas razvoja.
Pa tudi glede časa izvajanja ni zmeraj tako, da bi bil enak program v C-ju (ali javi ali kje drugje) hitrejši.
Meni je predvsem všeč to, da izhaja iz matematike in ne iz narave stroja, ki rešuje probleme (izvaja algoritme). Na ta način je kodiranje bolj osredotočeno na vsebino problema in manj na dajanje navodil stroju, kako naj nek problem reši.
Ampak CPu je podlaga vsega. In ta podlaga izvaja stvari klasično.
Se pravi, če potrebuješ neko transformacijo svoje kode v dejanjski program in je ta transformacija netrivialna, imaš problem.
Če bi bil največji problem to, bi vsi pisali programe v strojnem ali zbirnem jeziku. Višjenivojski programski jeziki imajo pač netrivialne prevajalnike, ki ne transformirajo vedno programske kode v strojni jezik optimalno (pa vendar mnogokrat to storijo bolj optimalno, kot če bi se nekdo sam spravil pisat program v asm). Imajo pa druge prednosti.
Priznam pa, da kar se tiče dela v podjetjih, še nikoli nisem imel priložnosti delati z lispom (se pravi, da je zame bolj kot ne hobi).
Tudi sam v praksi ne delam v lispu, uporabljam pa nek drugi soroden funkcijski programski jezik, ki je vgrajen v neko interno orodje, katerega pri delu rabim.
Sicer pa nekatere znane univerze svoje študente računalništva začnejo učiti prav funkcijske programske jezike. MIT je še do nedavnega v prvem letniku CS študente učil Scheme (nekaj let nazaj pa so ga sicer zamenjali s pythonom).
Menda zato, ker je lažje preklopiti način razmišljanja iz funkcijskega k proceduralnemu prog. jeziku (v obratni smeri ima marsikdo težave), pa tudi zato, da ne bi študentje prehitro začeli delati za denar in zapostavili študij (ker se lisp/haskell/scheme v praksi manj uporablja) :)
Zgodovina sprememb…
- spremenil: jernejl ()
jype ::
Pri delu z GIS rešitvami, ki so tesno povezane z Autodeskovimi orodji, je Autolisp precej standardno okolje, v katerem se programira in iz katerega sem se jaz naučil o lispu vse tisto, kar morda izgleda akademsko, pa je v resnici prekleto praktično.
No, potem sem nekaj let pozneje prebral še Paula Grahama in ugotovil, da nisem edini s takimi izkušnjami.
No, potem sem nekaj let pozneje prebral še Paula Grahama in ugotovil, da nisem edini s takimi izkušnjami.
Brane22 ::
Če sem prav razumel, gre za uporabo v vlogi skriptnega jezika, ki krmili določeno orodje.
Fajn. Tam pridejo ti aduti posebej do izraza. In tam hitrosti zvajanja samega jezika niti ni pomembna, ker ta proži orodje, ki bo itak požrlo praktično ves procesorski čas.
Ampak kakšen del vse kode dejanjsko je tak ?
In tudi če se spustimov ta svet, koliko je dejanjsko prihranka, če odštejemo učenje spet novega objektnega jezika ?
Će smo čisto picajzlasti, je tudi strojni jezik abstrakcija. Če bi šli do konca, bi najbrž morali šteti posamezne elektrone in simulirati učinek vsakega posebej v vezju.
Pač C/C++ nudita nivo abstrakcije, ki je znosen ob izkoristku HW, ki je za večino namenov dovolj dobra. Tistim, ki jim tudi to ni zadosti, je na voljo še kaka stopnica navzdol.
Ampak strukture in elementi v teh jezikih se _dokaj_ dobro preslikajo v executable. Pa še tega nivoja abstrakcije nismo uspeli dobro premagati, saj ima prevajalnik kupe in kupe opcij za nadzor optimizacije.
Fajn. Tam pridejo ti aduti posebej do izraza. In tam hitrosti zvajanja samega jezika niti ni pomembna, ker ta proži orodje, ki bo itak požrlo praktično ves procesorski čas.
Ampak kakšen del vse kode dejanjsko je tak ?
In tudi če se spustimov ta svet, koliko je dejanjsko prihranka, če odštejemo učenje spet novega objektnega jezika ?
Če bi bil največji problem to, bi vsi pisali programe v strojnem ali zbirnem jeziku.
Će smo čisto picajzlasti, je tudi strojni jezik abstrakcija. Če bi šli do konca, bi najbrž morali šteti posamezne elektrone in simulirati učinek vsakega posebej v vezju.
Pač C/C++ nudita nivo abstrakcije, ki je znosen ob izkoristku HW, ki je za večino namenov dovolj dobra. Tistim, ki jim tudi to ni zadosti, je na voljo še kaka stopnica navzdol.
Ampak strukture in elementi v teh jezikih se _dokaj_ dobro preslikajo v executable. Pa še tega nivoja abstrakcije nismo uspeli dobro premagati, saj ima prevajalnik kupe in kupe opcij za nadzor optimizacije.
Zgodovina sprememb…
- spremenilo: Brane22 ()
jype ::
Brane22> Ampak kakšen del vse kode dejanjsko je tak ?
Ogromen. Več kot 90% vse kode je zgolj lepilo za osnovne gradnike, ki požrejo več kot 90% vsega časa.
Brane22> In tudi če se spustimov ta svet, koliko je dejanjsko prihranka, če odštejemo učenje spet novega objektnega jezika ?
Prihranka je ogromno. Več tednov v C++ vs. en dan v visokonivojskem skriptnem jeziku.
Ogromen. Več kot 90% vse kode je zgolj lepilo za osnovne gradnike, ki požrejo več kot 90% vsega časa.
Brane22> In tudi če se spustimov ta svet, koliko je dejanjsko prihranka, če odštejemo učenje spet novega objektnega jezika ?
Prihranka je ogromno. Več tednov v C++ vs. en dan v visokonivojskem skriptnem jeziku.
Brane22 ::
Brane22> Ampak kakšen del vse kode dejanjsko je tak ?
Ogromen. Več kot 90% vse kode je zgolj lepilo za osnovne gradnike, ki požrejo več kot 90% vsega časa.
Maš kakšen link za tole ?
Brane22> In tudi če se spustimov ta svet, koliko je dejanjsko prihranka, če odštejemo učenje spet novega objektnega jezika ?
Prihranka je ogromno. Več tednov v C++ vs. en dan v visokonivojskem skriptnem jeziku.
Realen primer ?
jype ::
Brane22> Maš kakšen link za tole ?
Seveda ne.
Brane22> Realen primer ?
RabbitMQ vs. IBM MQ, prvi napisan v erlangu, drugi pa v C++.
Enega so pisali 20 let, drugega pa eno leto, nabor zmogljivosti je pa podoben.
Seveda ne.
Brane22> Realen primer ?
RabbitMQ vs. IBM MQ, prvi napisan v erlangu, drugi pa v C++.
Enega so pisali 20 let, drugega pa eno leto, nabor zmogljivosti je pa podoben.
Brane22 ::
Seveda ne.
Torej gre za tvojo oceno. Kaj si zajel vanjo - kodo na websajtih ?
RabbitMQ vs. IBM MQ, prvi napisan v erlangu, drugi pa v C++.
Dobro, to je ne ravno primerljiva malenkost. Tudi verjetno ne pisana s strani istega teama,z enakimi cilji in enako hitrostjo v enakih pogojih.
jype ::
Brane22> Torej gre za tvojo oceno. Kaj si zajel vanjo - kodo na websajtih ?
Svoje izkušnje - od ogromne MPI mašinerije do, če hočeš, PHPja.
Brane22> Dobro, to je ne ravno primerljiva malenkost. Tudi verjetno ne pisana s strani istega teama,z enakimi cilji in enako hitrostjo v enakih pogojih.
To je bistvo, o katerem se pogovarjamo - koliko dela prihranijo boljša orodja v odnosu do tega koliko ciklov požrejo v zameno za to.
V času, ko je time-to-market praktično največja možna konkurenčna prednost, cikli so pa praktično zastonj, niti ni težko ugotoviti, zakaj vsa podjetja s kupi denarja večino funkcionalnosti razvijejo nad orodji, ki so "počasna in nerodna".
Svoje izkušnje - od ogromne MPI mašinerije do, če hočeš, PHPja.
Brane22> Dobro, to je ne ravno primerljiva malenkost. Tudi verjetno ne pisana s strani istega teama,z enakimi cilji in enako hitrostjo v enakih pogojih.
To je bistvo, o katerem se pogovarjamo - koliko dela prihranijo boljša orodja v odnosu do tega koliko ciklov požrejo v zameno za to.
V času, ko je time-to-market praktično največja možna konkurenčna prednost, cikli so pa praktično zastonj, niti ni težko ugotoviti, zakaj vsa podjetja s kupi denarja večino funkcionalnosti razvijejo nad orodji, ki so "počasna in nerodna".
Zgodovina sprememb…
- spremenilo: jype ()
Brane22 ::
V času, ko je time-to-market praktično največja možna konkurenčna prednost, cikli so pa praktično zastonj, niti ni težko ugotoviti, zakaj vsa podjetja s kupi denarja večino funkcionalnosti razvijejo nad orodji, ki so "počasna in nerodna".
Cikli niso nikoli zastonj.
Brane22 ::
Nekako tako kot je hrana v zaporu zastonj.
Poglej si stalen benchmarking vsega od CPUjev preko grafikulj, RAM-a, diskov in celo telefončkov in tablet.
Zakaj to, če so cikli zastonj ?
Poglej si stalen benchmarking vsega od CPUjev preko grafikulj, RAM-a, diskov in celo telefončkov in tablet.
Zakaj to, če so cikli zastonj ?
Zgodovina sprememb…
- spremenilo: Brane22 ()
jype ::
Brane22> Zakaj to, če so cikli zastonj ?
Zakaj se folk samozadovoljuje? It feels good.
Optimizira se lahko pozneje, ko si že zasut z denarjem.
Zakaj se folk samozadovoljuje? It feels good.
Optimizira se lahko pozneje, ko si že zasut z denarjem.
Brane22 ::
Brane22 ::
jype ::
V resnici to drži za vse izdelke. Biti pa morajo zgolj dovolj dobri, nič več.
Bolje je, da izdelki pridejo dva meseca prej na trg, kot da so po nekih benchmarkih najboljši (za tistega, ki jih bo lansiral).
Človek se lahko samo za glavo prime, ko vidi kako v iOS deluje uporabniški vmesnik - ampak ljudje so z njim očitno zadovoljni.
Bolje je, da izdelki pridejo dva meseca prej na trg, kot da so po nekih benchmarkih najboljši (za tistega, ki jih bo lansiral).
Človek se lahko samo za glavo prime, ko vidi kako v iOS deluje uporabniški vmesnik - ampak ljudje so z njim očitno zadovoljni.
sherman ::
Se pravi, če potrebuješ neko transformacijo svoje kode v dejanjski program in je ta transformacija netrivialna, imaš problem.
Izvesti jo mora nek mehanizem, rezultat pa ne bo vedno optimalen.
Enak argument, en nivo visje bi sel nekako tako. "Se pravi ce potrebujes neko transformacijo svojega problema v kodo in je ta transformacija netrivialna, imas problem. Izvesti jo mora nek mehanizem (tvoji mozgani), rezultat pa ne bo vedno optimalen."
V resnici znamo razumne funkcijske programe v resnih programskih jezikih (mnozica, ki vkljucuje vsaj SML, Ocaml in sorodnike) zelo dobro prevesti. Na primer deset let star tutorial da lep pregled osnov. Toliko dobro, recimo, da so sistemi za hitro trgovanje dostikrat napisani v kakem od teh.
In dober programer se bo pri tezkih problemih pogosto zatekel k abstrakciji, da bo problem (p)ostal obvladljiv. Lahko bo rocno zgradil to abstrakcijo v C-ju in potem rocno optimiziral, lahko pa bo vzel programski jezik, ki omogoca enostavno gradnjo abstrakcij. Prednost slednjega je tudi, da je veliko ljudi razmisljalo kako prevesti te abstrakcije v ucinkovite programe in tudi prevajalnik takega jezika ima na voljo veliko vec uporabnih informacij in zagotovil, kot pa C prevajalnik.
Da ne bom narobe razumet, ne pravim da je vedno bolje vzeti Ocaml (ali katerikoli drug jezik), ampak trditi da imata C ali C++ pravi nivo abstrakcije za vecino problemov, je pa tudi zgreseno. V C-ju tako ali tako nimas nobene resne abstrakcije.
In uporabno je tudi, ce lahko kaj poves o tem, da bo tvoj program prav delal. Vsak lahko pise hitre programe, ki narobe delajo.
Strinjam se tudi z Brane22, da je hitrost pomembna. Besen sem, ko mi dandanes trivialne operacije trajajo zaznaten cas. A besen sem tudi, ko je stvar polovicarsko narejena, kot pravi jype da je pomembno, potem pa mi skoraj vsak kurcev python program pise stack trace zaradi razlogov, ki so bili v spodobnih jezikih odpravljeni 20 let nazaj. Pa ko mi, ko vklopim bluetooth, crkne zvok v predvajanem videu.
noraguta ::
Pri delu z GIS rešitvami, ki so tesno povezane z Autodeskovimi orodji, je Autolisp precej standardno okolje, v katerem se programira in iz katerega sem se jaz naučil o lispu vse tisto, kar morda izgleda akademsko, pa je v resnici prekleto praktično.
No, potem sem nekaj let pozneje prebral še Paula Grahama in ugotovil, da nisem edini s takimi izkušnjami.
AutoCad kod gis orodje in auto lisp kot standardno okolje, so stvari katere zveš zgolj na slo techu.
Pust' ot pobyedy k pobyedye vyedyot!
jype ::
noraguta> AutoCad kod gis orodje in auto lisp kot standardno okolje, so stvari katere zveš zgolj na slo techu.
Mhm, tako je to, če se človek ukvarja z motorkami, pa pride v IT. Vse je čudno!
Mhm, tako je to, če se človek ukvarja z motorkami, pa pride v IT. Vse je čudno!
noraguta ::
:~>>>>> faliran fizik brez osnov matematke, je res cenjeno blago. sploh če zna python! :~)))) še tisto malo podpore da se autocad(map 3d) povezuje na gis sisteme je narejeno kot COM kontrole. ampak če človek ve in dela stem potem ve!
Pust' ot pobyedy k pobyedye vyedyot!
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Jeziki specifičnih domenOddelek: Programiranje | 2295 (1928) | noraguta |
| ⊘ | Učenje programiranjaOddelek: Programiranje | 1079 (989) | Gandalfar |
| » | S katerim programskim jezikom narediti prve korake v svet programiranja ? (strani: 1 2 )Oddelek: Programiranje | 6621 (5024) | b |
| » | Programski jezik LispOddelek: Programiranje | 2247 (1408) | OwcA |
| » | Seznam programskih jezikovOddelek: Programiranje | 2310 (1934) | BigWhale |