Programarea funcțională

Programarea funcțională ma atrăgat întotdeauna în opoziție cu imperativul.
Foarte adesea discut diverse aspecte ale programării funcționale pe diverse ramuri ale Marketplace.






Dar aș vrea să adun pe toți cei interesați de acest subiect într-o ramură.
Cred că este timpul să deschidem un astfel de subiect. Și de asta.

Din punct de vedere istoric, programarea funcțională a apărut aproape în legătură cu imperativul.
Cea de-a doua limbă după Fortran a fost liz.
Dar, din păcate, programarea funcțională pentru mult timp a fost o mulțime de institute de cercetare sau aplicații specializate (Inteligență artificială)
Desigur, întreaga lume nu ar trebui să fie considerată proști, deoarece dezvoltarea a mers pe calea limbilor lui Algol.
Au existat motive destul de obiective pentru acest lucru. Limbile funcționale sunt prea apropiate de om și sunt prea departe de mașină.
Mănâncă zeci de ori mai multe resurse decât limbile imperative.
pretenții de rechemare predyavlyaemye la java - primul limbaj imperativ, cu o mașină și colector de gunoi virtuale, împins de marile corporații în mainstream.
Foarte frânează și mănâncă toată memoria ce este. Dar limbile funcționale (denumite în continuare "PO") toate fără excluderi au un colector de gunoi, o mașină virtuală.
Multe dintre ele (familia lizelor) sunt de asemenea dinamice, ceea ce agravează doar situația.
Este destul de natural ca, după ce au apărut cu mai mult de cincizeci de ani în urmă, aceștia sunt pentru mult timp înainte de timpul lor.

Pentru distribuția largă a FW, sunt necesare gigabytes de memorie ieftină și procesoare ieftine de la Gigahertz.
Au trecut mai mult de 50 de ani înainte ca astfel de cerințe pentru fier să devină o realitate.
De data asta a venit. ACUM.
Bine ați venit în noua eră a programării.

Total în 5500 de posturi

>> Total posturi în subiecte: 5500; pagini: 550; pagina curentă: 259

Răspundeți la "mesaj 2919" (Geniepro)
___________________________
Pentru CGI. Poate fi mult mai simplu - mod_proxy
La mine lisp serverul și locul de muncă de sub apache.






Câți dintre aceștia au văzut aceste fișiere - nu le-au acordat atenție, și apoi au făcut o mențiune despre asta pe blogul Everything Scheme

Aici, cine vrea să studieze FP folosind schema ca exemplu, poate face acest lucru făcând un site web.
Interesant, dacă distribuția Linux a DrScheme este instalată pe Apache ca CGI, va funcționa pe orice servere de pe Internet?

Ați câștigat deja peste oamenii de știință. Opriți amorsarea pompei. rune algebrice, vrăji din Cartea teoria categoriilor, banane, lentile, săgeți, cata, ana, hylo, endo, totul este deșertăciune.

Nu puteți interesa inginerul cu noi trucuri. El a petrecut prea mult, stăpânind, trucuri dificile pentru a lucra. Avantajul său competitiv și reputația prețioasă sunt în joc. Dă-l să creadă că el este pe punctul de a fi "lăsat în urmă".

Pe site-ul "Desert Spring-Time: O'Caml Operating System", a fost creat un proiect pentru crearea unui OSE pe OAML (și parțial pe C). Deși nu se face mult, așa cum am înțeles, dar proiectul este deschis celor care doresc să participe la el: o listă de sarcini pentru cei care au decis să ajute proiectul.

Răspunsul la "mesajul 2912" (Geniepro)
___________________________

Erlang în această privință este mai mult ca Lisp - semantică strictă (viguroasă) cu semantică dinamică.

Ugh. Cu tastarea dinamică, desigur.

Răspunde la »mesaj 2910« (Interesat)
___________________________

După cum înțeleg, Erlang este mai concis, bibliotecile și instrumentele sale sunt mai bune decât cele ale lui Haskell.

Haskell și Erlang au ideologii foarte diferite, deși acestea sunt ambele FW.
Haskell este o limbă cu semantică non-strictă (leneș) cu tastare statică.
Erlang în această privință este mai mult ca Lisp - semantică strictă (viguroasă) cu semantică dinamică.

În ceea ce privește laconicitatea mai mare a lui Erlang, întrebarea este controversată.


Și principalul lucru (pentru mine) avantajul FY este simplificarea programării pentru sistemele multi-core, este mai relevantă pentru Erlang și nu pentru Haskell. În paralelizare explicită Erlang, care deja funcționează minunat, dar în dezvoltatorii Haskell încearcă să se dezbrace cu implicit. În opinia mea, acesta este un drum mort. Nu poți să te automatizi așa. Decizia care paralelizează, este necesar să se lase la dezvoltator.

De fapt, Haskell a avut mult timp posibilitățile programării paralele explicite: Parallel Haskell, Concurent Haskell, Distributed Haskell.

Asamblarea unui program de mare paralel corect din gramada de mici rutine paralele corecte chiar și într-o FYA pură - nu o astfel de sarcină ușoară, și, eventual, trebuie să transfere astfel de chestiuni traducătorului, mai degrabă decât persoana, lasandu-l cu posibilitatea de a da indicii compilatorului unde zhedatelno parallelized.

Răspuns la »mesaj 2909« (Max Belugin)
___________________________

"De ce FY?" Sau merită învățat ceva radical diferit de C ++ / Java / Python
Acum Jack se va întoarce și va spune că Python nu este curat IH, ci mai degrabă mai aproape de Lisp :-)

>> Total posturi în subiecte: 5500; pagini: 550; pagina curentă: 259







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: