This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-07-03
Channels
- # announcements (13)
- # babashka-sci-dev (8)
- # beginners (214)
- # calva (2)
- # cider (32)
- # clj-on-windows (17)
- # clojure (88)
- # clojure-conj (2)
- # clojure-europe (26)
- # clojure-nl (1)
- # clojure-norway (27)
- # clojure-sweden (12)
- # clojure-uk (5)
- # cursive (16)
- # datalevin (4)
- # emacs (7)
- # events (2)
- # graalvm (8)
- # honeysql (8)
- # humbleui (7)
- # jobs (7)
- # joyride (46)
- # london-clojurians (1)
- # lsp (13)
- # malli (3)
- # off-topic (9)
- # pathom (14)
- # pedestal (11)
- # polylith (4)
- # reitit (2)
- # releases (3)
- # remote-jobs (3)
- # xtdb (65)
Har ni tänkt på att Clojure-experter pratar om helt andra saker än JavaScript-experter? Till exempel: När JavaScript-experter säger “Use maps instead of objects” menar de nästan tvärt om mot vad RH menar i den där fina ranten. JavaScripts motsvarighet till Clojure maps är väl ändå objects? Men de är så nedlusade med OO att experterna tycker att de skall undvikas. I stället ska man böka med instanser av Maps. Att det har sjukt mycket sämre ergonomi än den enkla syntaxen med objects, eller att man behöver hjälpa GC med att komma ihåg weak
, verkar inte bekomma det minsta.
Ergonomin kring maps är verkligen förvånande. Jag lockades av tanken med att använda en "ren" data-behållare till skillnad från objekt, men det gick inte att motivera varken för mig själv eller teamet när man såg hur koden blev.
Det finns mycket att beakta här, när jag hoppar iväg ifrån Javascript. Vi har OO varianten som i ranten, en röra: där det är svårt att förstå strukturen och någon annan har dikterat hur vi ska göra. Vi har maps: där vi kan använda ett fåtal välkända verktyg och det mesta är synnerligen enkelt. Vi kan välja själva hur vi vill jobba med i det här fallet en Http request. Sen har vi records som i de statiskt typade språken: där vi fortfarande har tydligt enkla associativa samlingar, med någon slags garanti på hur strukturen är. Vi kan fortsatt bestämma själva hur vi arbetar med domänen, utan att någon annan har dikterat för mycket. Jag tänker här också på de gamla "algoritmiska" språken: Pascal och Ada där vi har de statiska range typerna. Vad hände med den idén? I den där Java-röran, finns det fortfarande någon slags garanti på hur strukturen ser ut, även om den är svår att förstå. Vi kan i någon mån förlita oss på att andra också känner till hur detta förutbestämda sätt att arbeta med just Http är. Samtidigt har såklart författaren missat en hel del, och alla får anpassa sig till dessa felaktigheter, vilket såklart kostar mycket. Ju bättre det där statiskt typade språket är, ju närmare den där enkla Clojure modellen kan den komma, men en garanti för hur strukturen av maps ser ut. I Clojure har vi en förutfattad bild på hur en Http request ser ut. Även om det är en nära översättning av hur data ser ut på linan så har vi väl här några antaganden som typsystemet inte hjälper oss med. Jag tycker ranten med Http är lysande, men allt är inte så enkelt strukturerat som en http request. En modell som är "ganska statiskt typad" ute på linan. Vi vet hur den ser ut, så den är enkel att modellera i ett statiskt typsystem. Dynamiskt data, som ett json dokument, blir svårt att modellera statiskt. Här blir ett dynamiskt typat funktionellt språk med enkla typer som mappar, vektorer och sent evaluerade sekvenser svårslaget. Det mesta är väl dynamiskt typat
Också tänkt och upplevt något liknande @U0ETXRFEW. Efter mina tidigare Java/Go/JS jobb så är diskussionerna helt annorlunda nu. Mycket mer fokuserade på "essentiel komplexitet" - att lösa det faktiskta problemet. Funderar på vad vi Clojurister sitter och svamlar om nu, som man kommer tycka var helt onödigt om ett par år?
Spenderat en hisnande mängd tid på Hibernate, Spring, diverse XML konfigurationer, SOAP och allt möjligt, för att bara nämna Java saker.. 🙂
Har också funderat en del på vad det är som är Extensible i XML. Var det nån som nämnde ett annat extensible data format man kan skriva källkod i?
Jag har ljuva minnen av XSLT. Väldigt knäppt språk, men något med det och mig passar ihop. (Kanske jag också är knäpp.)
XSLT. Ett deklarativt språk utan sidoeffekter, med immutability och rekursion med första klass funktioner. Skrivet i ett konstigt format som tydligen är extensible