Funkcionális programozás
A funkcionális programozás mindig is felkeltett engem a kényszerrel szemben.
Sokszor beszélek a funkcionális programozás különböző aspektusairól a piacon lévő különböző ágazatokban.
De szeretnék összegyűjteni minden érdeklődőt ebben a témában egy ágban.
Úgy gondolom itt az ideje, hogy ilyen témát nyitjunk meg. És ezért.
Történelmileg a funkcionális programozás szinte összefüggésben állt a kényszerrel.
Fortran után a második nyelv volt a lisp.
De sajnos, a funkcionális programozás sokáig a kutatóintézetek vagy a speciális alkalmazások (mesterséges intelligencia)
Természetesen az egész világot nem szabad bolondnak tekinteni, mert a fejlődés az Algol nyelvének útján ment végbe.
Ennek egészen objektív okai voltak. A funkcionális nyelvek túl közel vannak az emberhez és túl messze a géptől.
Több tucatnyi erőforrást fogyasztanak, mint a kötelező nyelveket.
Emlékezzenek a java-ra vonatkozó követelésekre - az első kötelező nyelv egy virtuális gép és egy szemétgyűjtő által a nagyvállalatok által a főáramban.
Rettenetesen fékez, és eszik az összes memóriát, ami az. De a funkcionális nyelvek (a továbbiakban: "PO") minden nélkül kizárva egy szemétgyűjtő, egy virtuális gép.
Sokan közülük (a liszkák családja) is dinamikus, ami csak súlyosbítja a helyzetet.
Természetes, hogy több mint ötven évvel ezelőtt megjelentek, régóta vannak az idejük előtt.
Széleskörű FYA szüksége gigabájt memóriával és egy olcsó olcsó gigahertz processzorok.
Több mint 50 év telt el, mielőtt a vasnak ilyen követelmények lettek volna.
Ezúttal eljött. MOST.
Üdvözöljük a programozás új korszakában.
Összesen 5500 hozzászólás
>> Összes hozzászólás a témában: 5500; oldalak: 550; aktuális oldal: 259
Válasz a "2919 üzenet" (Geniepro)
___________________________
Mi a CGI. Sokkal egyszerűbb lehet - mod_proxy
Számomra a kiszolgáló és az apache alatt dolgozom.
Hányan láthatták ezeket a fájlokat - nem figyeltek rájuk, aztán megemlítették ezt a Blog Everything Scheme blogon
Itt, aki például a Scheme segítségével szeretné tanulmányozni az FP-t, ezt egy weboldal készítésével teheti meg.
Érdekes, hogy ha a DrScheme Linux disztribúciója az Apache-ra CGI-ként van telepítve, akkor minden internetes kiszolgálón fog működni?
Már megnyerted a tudósokat. Állítsa le a szivattyút. Algebrai rúnák, varázslatok a kategóriaelmélet könyvéből, banánok, lencsék, nyilak, cata, ana, hylo, endo, minden hiúság.
Nem érdekelheti a mérnököt új trükkök. Túl sok időt töltött, elsajátította, nehéz, trükköt dolgozni. Versenyelőnye és elismert hírneve forog kockán. Hozd el neki, hogy higgye el, hogy a "hátrahagyott" küszöbén áll.
A "Desert Spring-Time: O'Caml operációs rendszer" weboldalon megnyílt egy projekt, melynek célja az OSE létrehozása az OAML-on (és részben a C-ben). Bár nem sok mindent megtesz, ahogy megértettem, de a projekt nyitva áll azok számára, akik részt kívánnak venni benne: olyan feladatok listája azok számára, akik úgy döntöttek, hogy segítenek a projektben.
A "2912 üzenet" (Geniepro)
___________________________
Erlang ebben a tekintetben inkább olyan, mint a Lisp - szigorú szemantika (erőteljes), dinamikus szemantikával.
Huh. Természetesen dinamikus gépeléssel.
Válasz »üzenet 2910« (Érdeklődöm)
___________________________
Ahogy értem, Erlang sokkal tömörebb, könyvtárai és eszközei jobbak, mint Haskellé.
Haskell és Erlang nagyon különböző ideológiákkal bírnak, bár ezek mind FW-k.
A Haskell egy szigorú szimultán nyelv (lusta), statikus gépeléssel.
Erlang ebben a tekintetben inkább olyan, mint a Lisp - szigorú szemantika (erőteljes), dinamikus szemantikával.
Ami Erlang nagyobb lakonicit, a kérdés ellentmondásos.
És a legfontosabb dolog (számomra) az FY előnye a többmagos rendszerek programozásának egyszerűsítése, sokkal inkább Erlang, és nem Haskell számára. Az Erlang explicit párhuzamosítása, amely már csodálatosan működik, de a Haskell fejlesztői próbálkoznak a hallgatással. Véleményem szerint ez egy halálos út. Nem lehet mindent automatizálni. A döntés, amely párhuzamosan szükséges, el kell hagynia a fejlesztőnek.
Valójában Haskell régóta rendelkezik a nyílt párhuzamos programozás lehetőségeivel: Parallel Haskell, Concurent Haskell, Distributed Haskell.
Összeszerelése egy nagy helyes párhuzamos programot a halom kis helyes párhuzamos rutinok még egy tiszta FYA - nem olyan egyszerű feladat, és valószínűleg kell váltani az ilyen ügyekben a fordító, hanem az a személy, így neki a lehetőséget, hogy tippeket, hogy a fordító, ahol zhedatelno párhuzamosított.
Válasz erre »üzenet 2909« (Max Belugin)
___________________________
"Miért éppen az FY?" Vagy érdemes valami radikálisan különbséget tenni a C ++ / Java / Python-tól?
Most Jack visszajön, és azt mondja, hogy a Python nem tiszta IH, hanem inkább közelebb van a Lisphez :-)
>> Összes hozzászólás a témában: 5500; oldalak: 550; aktuális oldal: 259