Clojurians Log v2

Har du använt mapcat så har du använt en monad! 😉

Men räcker det för att kalla min programmering FP? 😃

Monader och dylika saker handlar om abstraktioner och väldigt generiska namn på vad man redan använder som utvecklare

Använder du comp eller threading macros och skriver pure functions så tycker jag det är solklart FP.

Så du kan använda kategori teori koncept även i icke FP språk

Intressant nog är det väldigt enkelt att implementera monader i C#, men extremt irriterande att implementera comp.

Jag älskar comp (och även partial). Vet att det finns hatare, men jag har aldrig förstått varför. 😃

😂. Det blir väl mer aktuellt att prata om monider av funktorer, när man sätter typetiketter på saker för att lova andra vad data är. För mig handlar funktionell programmering om att reducera rörliga delar. Monider och funktorer var för sig har nog sin plats i ett clojure vokabulär, om man nu vill diskutera i typ jargong.

Min poäng var alls inte att diskutera i jargon. Min poäng var snarare att peka på att jargon sväller ut och döljer FP-begreppet.

Om man definierar funktionell programmering som att främja/föredra användandet av funktioner (istället för klasser, metoder, …) så inkluderas clojure i allra högsta grad :) Det är väl också bra om funktioner och högre ordningens funktioner är en ”1st class feature” men behöver med den här definitionen inte vara typade eller för den delen ens rena, även om det kan vara att föredra 😅

Jovisst, men monaden blir effektiv i fp-begreppet när man har typ etiketter för att lova något. Monader framträder mycket mer i Elixir även om det är dynamiskt typat.

Jag använder begreppet lite som att främja användandet av data som värden. Men av det följer ju att användandet av funktioner också främjas.

Skulle tro att Clojure är mer data-centriskt än andra FP-communities.

Det verkar för mig som att “vi” rört oss ditåt. “Vi” för att det nog hände innan jag hittade Clojure. Men när jag började så var det vanligare med makro-tunga bibliotek än det är idag.

T ex. Secretary vs Bidi/Reitit.

Jag tycker clojure är väldigt funktionellt. I F#, som är ett statiskt typat språk, med väldigt avancerat typsystem använder man gladeligen arrayer och mutable state på mycket mindre kontrollerat sätt än Clojure. Jag fick ångestattack och portade vector och atom från Clojure första gången jag hade ett F# jobb. Naturligtvis som monad 😁 och all typteori påklistrad. Jag tycker man kan vara data orienterad i F# utan större problem... bara man slapp arrayer. Metaprogrammering, som macros, är mycket enklare i Clojure. Men jag tycker Clojure är en mycket effektivare sätt att leva med system. Jo jag saknar monader i bland... men de är ivägen mycket oftare än jag saknar dem när de är på plats. Clojure är mer funktionellt för mig då det är lättare att utesluta rörliga delar, immutability och externa effekter.

@andreas179, som fortsättning på din (som klasser och metoder). Jag tycker inte objekt orientering är något som motsätter sig funktionellt. Elixir och Erlang är exempel på FP och OO på ett trevlig sätt. Vi har enkel dynamisk dispatch, genom att vi skickar medelanden till actorn. Actorn tar ägarskap av sin representation på ett bra sätt, mycket bättre än Java och C# normalt gör, som bara läcker ansvar hela tiden. Jag skrev av mig lite på det här ämnet ganska nyligen. https://lucidglitch.com/posts/ooisexpensive/

@stefanvstein Jag håller med om att det finns både bra och mindre bra exempel på OO och säkert även FP. Jag försökte vara lite bredare i min definition av vad funktionell programmering skulle kunna vara så visst är inte jag rätt person att diskvalificera OO :) FP som ett förhållningssätt till data och beteende resonerar med mig även om alla säkerligen inte skulle hålla med 😁

@stefanvstein vad gillar du F#+?

@stefanvstein jag skulle definiera OOP enligt följande från din artikel: > An object’s state changes through time. An object has an initial state, followed by new states. It has one state before receiving a message and another afterwards. The difference between those values is the change caused by the message. > Comparing the state before and after a message separates what objects tend to combine: identity, value, and time. The identity remains the same, while distinct values describe the object at different points in time. Antar att du inte håller med då du säger att OOP och FP inte nödvändigtvis motsätter sig varandra. Eller har jag misstolkat något?

@ozzymcduff Jag tycker inte om F#+. Det bygger på Statically Resolved Type Parameters, villket är en konstig sidoeffekt i kompilatorn. SRTP används för att försöka efterlikna Haskells typklasser. Det ser trevligt ut att kunna överlagra operatorer, att få F# att se ut som Haskell. Det är trevligt från början, men plötsligt börjar kompileringstider bygga på, när varje typparameter ska resolvas. Jag har fått ta över projekt, som ingen velat vilja ta i, där kompileringstider och komplexitet var hårresande, vilket slängde mig in i ett depretionsliknande tillstånd. Jag tror man hade för mycket press, blivit stressad när kompileringstiderna drar iväg och lämnat systemet i produktion i ett bedrövligt skick. Själva iden med F# är ju att leva på typinferens. Editorn berättar för dig vad alla typer är. Currying blir ohållbart utan det. När det tar en minut att få fram typerna efter en knapptryckning, är det nära att man ringer ambulans. Vid annat tidigare tillfälle har jag själv försökt införa F#+, just för att det är trevligt med typklasser, men insåg problematiken, mycket tack vara en trevlig kollega. Den gången gjorde vi ett konkurrerande men mindre bibliotek för att kunna ha operatoröverlagring på några vanliga monader. Det var ok, men idag skulle jag nog inte använt SRTP över huvud taget. F# har andra kvaliteter, och är inte en strikt evaluerad Haskell.

@soltanzadehramin. I det urklippet ur min artikel tycker jag att jag beskriver OO på ett funktionellt sätt. En entitet som har ett tillstånd, som transformeras på ett kontrollerat sätt. Den har en identitet och olika tillstånd över tid.

@ozzymcduff https://lucidglitch.com/posts/fsharp-atom/

Trist att det blivit så @stefanvstein, jag gillar F#+, men använder det nog inte på samma sätt som du beskriver. Använder det rätt ofta i script och proof of concept applikationer innan det sedan portas över till mer konkreta typer (vilket förbättrar kompileringstider).

Ja, det blir snygg kod. Och i liten skala hinner man inte lida av kompileringstiderna. Men F# blir snyggt när det används som det är tänkt, även när det inte försöker vara Haskell. Jag tycker bara man ska vara försiktig med SRTP. F# har inte TypeClasses,

F#+ är inte tänkt att göra F# till Haskell utan snarare att återanvända lärdomar från olika andra abstraktioner. Möjligt att slutresultatet ser ut som att det liknar Haskell, men målsättningen är inte det.

Vi har jobbat rätt länge med att separera ut så att SRTP-koden i F#+ är separat från extenions-koden så att det går att välja delar av F#+ beroende på vilket behov man har.

Men det har inte gått så snabbt iochmed att det inte finns någon som betalar för det.

Aha. Du jobbar med det. Att separera SRTP koden låter som ett väldigt bra vägval. Precis vad jag önskat när jag använt det. I sådana bibliotek vill man verkligen plocka russinen i kakan. F#+ är rätt stort, och jag har själv inte analyserat på det djupet. Jag provade det första gången runt 2017, då vi instället gick med vårat egna lib. Problematiken där jag tog över ett projekt, var 2024. Som jag beskrev, tror jag projektet utfördes med allt för stor press. Det var bra många konstruktioner i koden som saknade relevans. Med kompileringstider och lite väl komplexa typkonstruktioner hade man förmodligen inte möjlighet förvalta koden på ett bra sätt under utveckling. Det var tydligen många som hade försökt, även erkänt duktiga F# programmerare, innan jag gav upp och skrev om det, och då helt utan F#+. Det skulle vara kul att se ett större projekt där F#+ fungerar bra. Här i ett Clojure community tycker jag det här också är själva svagheten med statiska typer. Plötsligt blir det ett hinder, och när det väl blivit ett hinder blir hindret snabbt ganska stort. Jag tycker det är väldigt tråkigt.