Clojurians Log v2

Morn!

Mrn. Pre-sommer lunch?

Morn!

Morn!

Morn!

Morn!

Morn

Morn

God morgen!

[...] fjerne detaljer fra koden som ikke bærer teori.Dette med å "bygge et vokabular for å prate om domenet" er også noe jeg bemerket meg fra #CKKPVDX53 - Christoph og Nate prater ofte om det. Det er også et tema som stadig dukker opp i Prolog community, som er enda mer deklarativt enn Clojure (Clojure's implementasjon av miniKanren i core.logic er basically samme konsept). Jeg tenker også på konspetene "essential tasks" og "accidental tasks" som definert av Fred Brooks i "https://web.archive.org/web/20160910002130/http://worrydream.com/refs/Brooks-NoSilverBullet.pdf" når dette temaet dukker opp.

Med Clojure og andre deklarative språk tenker man mer på hva en ønsker å oppnå ("essential tasks") og mindre på hvordan de tingene gjøres rent mekanisk ("accidental tasks.")

Jepp! Få vekk støyen, behold signalet. Da leser koden mye bedre! 😊

Egentlig er jeg veldig fascinert av logisk programmering i Prolog og core.logic Det føles nesten litt "magisk."

Fun fact: Joe Armstrong skrev den første versjon av Erlang i Prolog. Det var i 1986, samme året jeg ble født. Erlang ble skrevet om til C i 1989 og ble da 70x raskere enn Prolog-versjonen. https://www.erlang.org/blog/beam-compiler-history/ kan en lese hele den fantastiske historien/evolusjonen til BEAM.

Veldig spennnende at Armstrong & co implementerte hele Erlang én gang først før de begynte med lavnivå-koden. Først få ut hele problemet og hele implementasjonen, før man prøver å gjøre implementasjonen effektiv. Da vet man liksom hvordan dataen bør flyte gjennom systemet.

Ja, de dro "make it work, then make it better" til det ekstreme.

Så gjorde de implementasjonen ekstremt deklarativ først (Prolog), før de gikk low-level (C), og deretter (delvis) "self-hosted." Den store nedsiden med Prolog og logisk programmering generelt er at det er veldig treigt og ressurskrevende sammenlignet med andre fremgangsmåter.

Hvis logisk programmering hadde vært raskere hadde det vært den "beste" måten å "kode direkte i domenet" på.

Logisk programmering føles som neste naturlige steg i retningen høyere abstraksjon etter funksjonell programmering. Jeg venter i spenning på at noen skal implementere noe à la Prolog (idéen, ikke nødvendigvis syntaksen) på en mer effektiv måte, som gjør det realistisk å bruke utenfor akademiet.

Logisk programmering har ikke hatt sin "Rich Hickey" enda, hehe

Tja — skal teorien om programmet enkode dataflyten? Hvis nei er logikkprogrammering bedre, hvis ja, bør programmene våre ha en rekkefølge de må kjøres i. Jeg har hatt ugreie opplevelser med feilsøking når lazyness er involvert, både i Clojure (exception har tryna i urealisert slutten av en (map ,,)) og i Haskell. Hvordan dataen flyter er høyst relevant hvor hvordan koden yter!

Således er jo også Clojure en mening om hvilke verdier som bør være i språket! • Immutable data structures er verdt ytelseskostnaden, og bør fremmes helt til topp. • En del ytelsesgreier er ikke verdt teoristøyen. Folk som kritiserer Clojure fra lavnivå-perspektiv tar ofte tak i akkurat det; de ønsker ytelsesbeslutninger mer "in your face" enn det Clojure tilbyr.

Ja, enig. Men Clojure kan også ha god ytelse, ref. https://mino-lang.org/documentation/performance/ 🙂 Hadde jeg valgt Zig fremfor C kunne den vært enda raskere.

Jepp! Jeg skulle ønske feks Zig-godsakene kunne vært levert som en greie man brukte interkativt fra Clojure. Representere informasjonen at Zig-AST trenger i Clojure, og kompilere Zig-funksjoner interaktivt i REPL-loopen.

Kul tanke!

Clojure data -> Zig AST, JIT-aktig typ?

Det er opp til 3 lag med IR mellom Zig AST og maskinkode også, avhengig av plattform.

jepps!

tror utfordringen blir å gjøre det hyggelig å redigere. Hvis man er i en clojure-fil blir zig-style completions kjipt. Hvis man er i en Zig-fil blir Clojure-bruken kjip.

https://github.com/clojurewasm/ClojureWasm rusler i samme nabolag om ikke annet.

her ser det ut som de har implementert en ny Clojure-dialekt i Zig, og kompilert zig-koden til webassembly? jeg har liksom ikke lyst til å miste JVM-plattformen =/

Japp! Den der ligner mer på noe à la mitt eksperiment med mino

JVM-plattformen er ganske awesome! Jeg har et nytt prosjekt på trappene som bruker interop og Java libs (litt på samme måte som med https://eido.leifericf.com/).

Derfor er ontologi nyttig.

Morn!

Nå som såpass mange er enige om at programmering kan og bør sees som en øvelse i å bygge teori (Naur 1985), har jeg lyst til å løfte fram en annen, gammel, relatert ide: å se på notasjon som en måte å tenke på (Iverson, 1979). Jeg vet ikke nøyaktig hva Naur tenkte om programmeringsspråk, men la oss anta at han skrev C-liknende greier. Da blir notasjonen automatisk sløv, mellom linjene kode som uttrykker teorien blir det allokering, deallokering, ekstra argumenter for lengden på lister, etc. Når vi skriver Clojure fra dag til dag, kan vi gjøre en øvelse med å fjerne detaljer fra koden som ikke bærer teori. Da forfremmes koden fra enkoding av maskininstrukser til notasjon. Notation as a Tool of Thought (Kenneth E. Iversons Turing Award Lecture fra 1979) gir en haug med eksempler på når god notasjon gjør problemet og løsningen klar.