[...]
- * 2016 julkaistu Reason, "new interface to
OCaml", Facebookin projekti - * (oma syntaksi
OCamlille?) - * "Mitä vikaa Clojuressa": no
tarvitsin turvallisemman kielen jossa kääntäjä auttaa -
* Datomic kehuttu, "ihan kuin tietokanta olisi suoraan
omassa kielessä" - * Jälleen tämä dikotomia:
tyypit ovat mahtavia, mutta marshalling/serialisointi rikkoo ne. Eli
dynaamiset kielet tekevät tosi helppoa tietorakenteiden jakamisesta
verkon yli. - * ocaml-graphql-server: toteuttaa
GraphQL-skeemat OCaml-tyyppeinä - * eli
varsinainen motivaatio on jakaa tietotyyppimääritykset (skeemat)
palvelimen ja asiakkaan välillä
[...]
- * Kirjastoja, joilla GPU-ohjelmointi
helpottuu Clojuressa: ClojureCL, ClojureCUDA, Neanderthal, Bayadera
- * Pohjimmiltaan aivan samoja ratkaisuja kuin
Pythonin laskentatorni: "alternate hard and soft layers", NumPy, PyCUDA
- * CUDAssa on oma DSL (eräänlainen C-kieli),
jolla määritetään GPU-algoritmeja - * näiden
"CUDA-kerneleiden" linkitys tavallisiksi Clojure-funktioiksi
[...]
- * on todella vaikeaa tehdä DSL
ei-ohjelmoijille - * "DSL for non-programmers
needs IDE support" - * MPS on jonkinlainen
rakenteisen datan editointisysteemi - * MPS
"häviää excelille automaatiossa" koska makrot/ilmaukset -
* mutta tämä on ihan älytön väite, koska oikeasti tärkeämpää
on editoinnin UX, joka on kiinni vaikka mistä muusta -
* KernelF yrittää olla "määrittelykieli, joka keskittyy
DSL-käyttäjiä kiinnostaviin asioihin" (vähän kuin XML Schema), eli
lisää höpöhöpöä - * attempt type: unioni
normaaleista paluuarvoista yhdistettynä mahdollisiin
poikkeuspalautuksiin, käytännössä reifioituihin poikkeuksiin
- * vapaat, tavallaan SL-pohjaiset syntaktiset
sokerit - * "kernelF on tarkoitettu kieleksi,
jolla ei-ohjelmoijille on helppoa kirjoittaa oikeellisia ohjelmia"
[...]
- * Elm oli liian kätevä ja stabiili, ei
mitään syytä pitää koodaajaa - * mutta! 0.19
rikkoo kaiken! yay, nyt saa taas tehdä töitä
[...]
- * miten määritetään find-komennon tyyppi?
- * ehdotus: (s/cat (s/optional s/union :L :H)
String (s/many expression) - * tyyppiteoria
logiikan kautta: miten määritetään tyyppien merkitys? -
* SL:ien määrittely päättelysääntöinä: "konteksti" =
"täsmättämä merkkijono", SL = siitä seuraava fakta. -
* Pyrkii määrittämään yhden ison tyypin, johon pystyy
upottamaan kaikki tyypit - * konkatenaatio on
assosiatiivinen, mutta pari ei! - * näin voi
määrittää heterogeenisia listoja määrittämällä summatyypin osana tyypin
SL-määrittelyä - * katenaatio onkin Cons
- * SL-määrittelyn pointti on ehkä ennen kaikkea
se, että niillä on kätevä inline-syntaksi. - * ei
mitään järkeä oikeastaan laventaa kontekstittomiin kieliin, koska
sellainen tyyppimäärittelyjärjestelmä Haskellissa jo on.
[...]
- * DevOps: "write code -> huge side effects"
- * Miten oikeasti voi saada deklaratiivisia
ympäristökuvauksia? - * Pitää pitää
konfiguraatiokieli niin heikkona, ettei tule yleisiä koodin ongelmia?
- * Dhall on JSON + funktiot, tyypit, ja importit
- * Varmaan jonkinlainen template-kieli
- * Tietorakenteiden template-kieli? -
* importeissa on SHA256-varmisteet joilla voi huolehtia että
se tarkoittaa vielä samaa kuin ennen - *
Fabrizion pointti on tuottaa kaikki formaatteja Dhall:sta :)
- * Esimerkiksi Dhall-esiprosessori
Kubernetes-konffikselle - * hieno tapa leiskata
JSONia jossa pilkut on samalla tasolla kuin ne sulkeet joiden sisällä
ne on
[...]
- * "majestic talk about very complicated data
structures" -> rewrite this to be more fun - *
pysyvät tietorakenteet: tietorakenteet, jotka säilyttävät tilansa, kun
niitä muutetaan - * bagwell trie: applikatiivinen
taulukko (sekvenssi) - * hash-array map trie:
Rich Hickey toteutti nämä - * bit-mapped vector
trie: "index prefix trie"
----
[...]