Det är sjukt synd när nya kollegor vill "refaktorera" ditt fina system. Jag känner empati för dig i din situation. Till och börja med så låter det som att din nya ägare inte har erfarenhet. Man "portar" inte bara ett system till en helt nytt språk, ny databas etc. Gör en rewrite i så fall (fast varför lol). Men, jag ska ändå försöka komma på lite bra övertalningstips.

Känns som att bevisbördan ligger på den som vill ändra på något och inte på er? Oavsett så är det ju en sjukt stor röd flagga om en “ägare” vill mikromanagera, och det är ett problem som kommer vara långt mycket svårare över tid än att byta från en databas till en annan.

Håller helt med ^

En ägare bör fokusera på värdet av produkten och inte dess implementation. Diskutera på den nivån. Kommer era kunder att märka något skillnad ifall ni byter?

Och säg att det kommer ta 5 år innan det är portat ;) Då bör poletten trilla ner

Parallellt med att försöka hitta sätt att få den där idiotiska idén bort från bordet, skulle jag börja söka nytt jobb. Varningsflagga på den mikromanagern.

Galna människor med makt brukar det mest kosta energi att försöka ändra på. Flyt med och gör dina egna val, tänk framåt. ”Embrace change” och allt det där 😛 😀 Sorry, inte det du vill är ha, nej… (men inte är jag bitter 😋 )

Haha. Go @U0ETXRFEW, bättre uttryckt. 😎

Jag tror hälfen slutar i ett sånt här scenario. Men jag tror många Clojure programmerare är människor med som verkligen bryr sig, tålmodiga och lojala. De väljer att använda Clojure för att de verkligen tycker det är det bästa verktyget. De två kvarvarande kommer må dåligt, men de stannar kvar för produkten är verkligen en lösning på att viktigt problem. De kan så klart komma med riktigt bra motiveringar. Men vilka är det som biter, som skapar förståelse. Hur sticker man hål på idén?

Testa att måla upp pros & cons på en whiteboard. Visa rent grafiskt att det inte är en bra ide.

Typat? Ni kan lägga till typannoteringar i koden ifall er ägare tycker det är superviktigt. Precis som i typescript.

Produktivitet: Kommer att gå ner, och det kommer att ta längre tid att leverera.

Jag tror också att byta till Typescript och SQL är ett strategiskt beslut i det här scenariot. Man är oense om strategin

Utvecklarnöjdhet: Kommer att gå ner

Enkelhet att anställa nya utvecklare? Kommer dessvärre at gå upp... Så det är ett kort som kan dras från ägarens håll

Det också kan låta billigare med 10 javascript kodare i låglöneland än 4 välbetalda nära till hands.

Japp.... och är det så att det finns ett "beslut uppifrån" att byta implementation, så får jag nog bara ta och hålla med pez tyvärr...

Får man fråga vad ni bygger? 🙂

Utvecklarnöjdhet kommer nog inte gå ner på det stora hela. Kan man bara ett språk, så är det såklart det bästa språket som finns. Man kan ju gör allt med en hammare. Bara att kalla in en gäng javascriptare så har vi hög nöjdhet..

@U04JJEM2X1V Som jag beskrev. Ett modernt klassiskt system med backend i Clojure på JVM, med Clojurescript web i front end och en stor Datomic on prem lösning i backend. Jag har inte varit med och byggt det här systemet

”Det bästa verktyget är det du kan.” Ofta, i verkligheten. Sedan råkar det ju vara så, till stor frustration, att Clojure (lite som Linux) automatiskt sorterar bort de som bara leker. Det går liksom inte att låtsas kunna nåt (jämfört med Windows, Python, projektledning, chefande 😳 ). Men att generera värme på att bråka om det är väl sällan värt det.

Hade älskat att få vara i en sådan miljö. Nån gång. Bucket-list-grej det där 😅

Jag menar vad för produkt ni bygger. Blev nyfiken

(förstår att det kan vara känsligt ofc)

@UCW3QKWKT Jaha. Jag tycker Clojure är jättebra att bara leka med. Jag har lärt många och folk fattar riktigt fort. Det svåra är väl att lära sig lösa problem utan att använda föränderliga variabler. Att tänka rekursion. Sen är det väl bara att springa på. I mina ögon mindre bra programmerare som hoppar på tycker jag blir bra mycket bättre ganska snabbt.

Kul! Har du skrivit nånstans om hur du gör? Att få folk över någon slags jag-fattar-grejen-gräns brukar ju vara det svåra med Clojure.

@U04JJEM2X1V Scenariot är verkligt, men produkten jag beskriver stämmer inte. Jag är ute efter diskusion över hur man motiverar/försvarar en lösning i Clojure med bra programmeringsval.

Den här bilden tycker jag är rolig, och träffande 😀

@UCW3QKWKT Nej, jag har inte avhandlat hur man konverterar folk. Jag har jobbat med att få över folk till olika funktionella språk. Haskell, F# och Clojure. Och även hur man får folk att arbeta utan föränderliga variabler i imperativa miljöer som Java likaså. Det handlar väl mest om att teama upp och förklara fördelarna på vägen, och snart börjar de springa.

Efter att ha kodat Java sen 90-talet fick jag låta hjärnan göra ont ett tag när jag hoppade på Clojure 😋

@UCW3QKWKT Jag blev exponerad för Erlang på 90 talet, när jag satt med C++. I C++ kunde jag härmas ocf få fria funktioner med funktions operatorn: operator()(). Sen kom Java, och det gjorde ont igen. Jättekul med ett språk med inbyggt stöd för trådning... men.. Pizza, som snart blev Scala var en lösning. Med Clojure kunde jag lätta på trycket igen

Min frågeställning är: Hur motiverar man Clojure med tillhörande infrastruktur för någon som tycker TypeScript och SQL är lösningen på värdens problem?... Det är enkelt med en smart programmerare, men lite klurigare med affärsfolk som tror sig förstå programmering.

Jag tror det bästa är att försöka göra en så ärlig analys som möjligt. Tiden det tar att skriva om. Vad som skulle kunna bli gjort i stället. Värdet av en stack med stor användarbas kontra värdet av att vara nischad. Jämförelse mellan typiska antalet kodrader i de olika miljöerna. Statisk typning för-/nackdelar. REPL… Undersök om det finns exempel sedan tidigare. Om du postar frågan i #C03S1KBA2 , men ställer den mer hypotetiskt, kanske du kan undvika att svaren seglar iväg kring hur knäpp den nya ägaren verkar vara. Efterlys konkreta argument för och emot ett byte av teknik. Kanske inleda med att försöka minska kunskapsglappet? ”Här är läsning och videos som kan hjälpa dig att förstå de nuvarande valen lite bättre.” Det finns RH-videos och en del annat där ute. Jag tycker Rafael Dittwalds “Solving problems the Clojure way” är extra bra eftersom jag använder JavaScript för att få fram poängen.

@U0ETXRFEW för och nackdelar med statisk typning är självklar. Även om man är övertygad om statisk så finns det mycket att påvisa här. Hur man får system som är lätta att förändra. Att prata läckande abstraktioner och typer som hamnar i fel domäner osv. Jag tycker the REPL way är lite svår att förklara. Det låter lite väl scifi att säga att man blir mer integrerad med det körande programmet. Många tycker väl det låter ostabilt. Jag tycker väl att enkelheten som uppstår med att undvika förändringsbara variabler, isolera sidoeffekter är den stora fördelen. En lisp, med få datatyper är ju och störtskönt när man vill få till datadrivet. Enklare att ändra data än kod. Javascript är också bra för datadrivet. Jag tror man har gödslat med RH videos i det här fallet. Det brukar väl vara min medicin också. Rafaels videos har jag missat. Tack Peter... kvällen är räddad. Finns det några mer killer features som kan användas? Klart man kan starta diskutionen i #C03S1KBA2 Ville följa Linus exempel och säga gomorron, också.

Jag tycker att frågan kring statisk typning är svår. Gillar hur det är löst i TypeScript med att man kan välja hur mycket av det man vill göra. Min lista var inte avsedd att vara ens i närheten av komplett. Gav mest några exempel som låg nära tillhands. Min poäng var snarare att en sammanställning av läget är bra. såväl för er som för kostymerna. Om det finns en roadmap kan man kanske rita upp den alternativa roadmappen sida vid sida med några grova tidsuppskattningar. Det lyfter fram kunden i analysen (givet att roadmappen fokuserar på saker som leveras till kunden). När man tar sådana här beslut är det bra att ha lika bra koll på vad man väljer att inte göra som det man väljer att göra, tänker jag.

REPL-frågan är svår att göra till ett starkt argument eftersom kunskapsglappet hindrar chefen från att förstå vad det ens handlar om. Men kanske det går att göra en liten demo kring hur valda delar av systemet ändras med REPL:en och försöka göra en jämförelse med hur det går till med JS/TS-verktyg.

Kanske föreslå att ni mobprogrammerar ett tag och att chefen är inbjuden att delta? Clojure smittade av sig på mig på det sättet. 😃 (Jag var produktägare och inte kodare i det projektet).

Menar du verkligen datadrivet och inte dataorienterat? Jag bad ChatGPT göra en jämförelse av koncetpten: > Both “data-driven” and “data-oriented” are terms frequently used in the realm of development and decision-making, especially as organizations seek to harness the power of data for various purposes. However, they represent somewhat different concepts. Let’s break down each term: > 1. Data-Driven Development (or Decision-Making) > ◦ Definition: Data-driven development refers to a methodology or approach where decisions, ranging from product features to business strategies, are made based on data analysis and interpretation. This can encompass user metrics, A/B testing, analytics, and more. > ◦ Focus: The main focus is to base decisions on actual data rather than intuition or unsupported assumptions. This helps in validating hypotheses and ensuring that the developed features or changes will indeed bring the desired results or benefits. > ▪︎ Examples:Using user behavior analytics to refine a user interface. > ▪︎ A/B testing different versions of a web page to see which one has a higher conversion rate. > ◦ Analyzing sales data to decide which products to promote or discontinue. > 2. Data-Oriented Development > ◦ Definition: Data-oriented design (or development) is more of a programming paradigm, particularly relevant in game development and real-time systems. It emphasizes memory layout and accessing patterns to ensure that data structures and algorithms are optimized for the specific hardware they run on, particularly the cache hierarchies. > ◦ Focus: The main focus is on performance optimization. In a data-oriented approach, developers often think first about the data and its layout and then about the operations on it. This often contrasts with Object-Oriented Programming (OOP) where the focus is on bundling data and operations (methods) into objects. > ▪︎ Examples:In a game, instead of having a list of enemy objects (OOP style), a data-oriented design might involve having separate contiguous arrays for enemy positions, enemy health, enemy types, etc., to allow for faster and cache-efficient processing. > ◦ Systems that process large streams of similar data (like particle systems) might be designed with a data-oriented approach to maximize throughput. > Comparison: > • Purpose: Data-driven development is more about making informed decisions based on actual data. Data-oriented development, on the other hand, is about optimizing code performance by designing it around efficient data access patterns. > • Scope: Data-driven development is generally more broad in its application, relevant to many domains and industries, while data-oriented development has a narrower scope, frequently seen in performance-critical applications. > • Approach: Data-driven relies on collecting, analyzing, and interpreting data. Data-oriented focuses on how data is laid out in memory and how it’s accessed by the CPU for maximum performance. > In essence, while both concepts revolve around data, they focus on different aspects of development and decision-making. One is about guiding decisions with data, while the other is about architecting software in a way that optimizes data access for performance.

Vad kallar vi data driven/oriented som vi använder det i Clojure, där vi använder datastrukturer som inte representerar kod, för att beskriva programflöde? När vi utnytjar att det är lättare att ändra data än kod? Kan vi komma bort från GPT:s definition här?

Jag menar data orienterat...

ChatGPT är som vanligt väldigt babblig och lyckas ändå missa mycket. Men jag gav den inte Clojure-sammanhanget, så lite ursäktad är den ändå.

Ja, och den anpassar sig ju när man håller en dialog 🙂

Det finns för övrigt prominenta Clojurianer som verkar ogilla dataorienterat. Eller i alla fall en.

Det är ett verktyg. Ibland passar det bra, och ibland är det irriterande. En fördel med Clojure är dess enkelhet, som gör att man kan använda verktyg a la carte.. Men så är det väl i Javascript också

Svårt att tyda om det är så hon menar: https://twitter.com/janetacarr/status/1603437933960257539

Använder ni specs?

Integrationskod, kod som limmar ihop väl genomtänkta funktioner kan ses som konfigurationskod... Om man ändrar på koden ändrar man konfigurationen. Återanvändbarhet. Men det är ett bra inlägg. Visst anskyr vi att limma ihopp java komponenter med XML, eller konstiga containrar med godtyckling tolkning av annotations.

@U04JJEM2X1V Japp, det används nog Specs, Malli eller Schema, datavalideringsverktyg flitigt i koden. Grundläggande typer ska ha rätt protokoll, även om man gärna undviker Clojure types och protocols

@U0ETXRFEW ... Data orienterat, på det sätt att data representerar beteende, behöver ju inte alls betyda att data ligger utanför koden, som jag misstänker att Janet A. Carr syftar på. Idén är väl att det kan vara enklare att ändra på data i källkoden än att ändra på uttryck för vad som sker. Bra mat för att beskriva vad det handlar om. Tack

Perfekt, så har du ett till argument för clj > ts iaf ;)

@U04JJEM2X1V Vilket då? Både dataorienterat och validering av datastrukturer funkar fint i TypeScript. Men de är argument mot statisk typning, och för dynamisk typade system. Det är också väldigt vanligt med dessa tekniker i Clojure och en massa bibliotek anammar dessa stilar vilka gör det smidigt. + för Clojure

Får du automatiskt genererad validering av dina datatyper i ts, på samma set som i clj?

Jag tycker Janets kommentarer om konfigurering och dataorientering är konstiga. Men hon är mycket smartare än jag är, så jag håller öppet för att jag antingen missförstår kommentaren eller för att hon har rätt och jag har fel.

Man kan jobba dataorienterat i TS, men saker är mutable per default, så det är inte lika smidigt och säkert som det är i Clojure.

Jag vill gärna hindra att typinformation läcker otillbörligt inom domäner systemet. Dataorientering fungerar ofta som typ-barriär. Värt att tänka på om man använder det som konfiguration, eller om det förenklar systemet. Och jag känner mig inte heller särskilt smart 🙂

@U0ETXRFEW Japp, att Clojure har persistent strukturer rakt igenom, är ju en självklar fördel över TypeScript. Jättefördel att alla bibliotek osv följer denna paradigm. Det är inte tillräckligt att plocka fram det där persistent collections biblioteket i TypeScript, eftersom andra inte använder det.

Varför vill personen att det ska vara SQL+node?

I det här scenariot: SQL för att det är defakto för databaser. Det har fungerat sedan 80-talet och alla kan det. Node för att det är en fördel om samma språk kan kan användas både på klient och serversida. "Alla" kan javascript, och typescript är javascript med statisk typning. Att kompilatorns säger ifrån anses väl vara lösningen på alla problem.

Låter som säljsnack mot utveckling. Låter inte som den riktiga anledningen som ägaren har.

Kan det vara att ägaren vill kunna anställa fler vanliga frontend-utvecklare?

Jag tror att det kan vara arrogans. Känner igen mig själv från när jag var yngre. Var tvärsaker på en massa saker som jag senare insåg att jag inte borde varit tvärsäker om…

Ja, beror rätt mycket på vem det kommer från.

Det verkar redan etablerat i den här tråden att man bettar på att en vanligare teknikstack gör det enklare med rekrytering?

Jag skummade den första delen

Jag tror att det kan vara både rätt och fel tänkt. Det går ju defacto en massa JS-utvecklare på en CLJS-utvecklare. Men det översätts inte automatiskt till bättre rekyteringsläge.

Har man bara en hammare så ser allt ut som en spik. Det är en bra anledning att kunna anställa fler vanliga front-end utvecklare. Frågeställningen är hur man beskriver fördelarna med Clojure och dess arkitektur för någon som tycker att Typeskript och Node är det bästa valet. Så pass bra att man är beredd att skriva om ett väl fungerande system.

Jag tror inte att det går att beskriva fördelarna tillräckligt bra för en sådan person. Men det kan mycket väl vara värt försöket ändå.

😄 Så dåligt är väl inte TypeScript. Brendan hade väl till en början i uppgift att skapa en Scheme till Netscape. Suns påverkan ställde väl krav att det skulle likna Java, och Javascript rullades fram efter 10 dagar. Anders är väl en vettig människa och Typescript är väl ett cfront liknande typsystem på Javascript... eller? Jag hade nog inte heller tyckt att Clojure var ett bra verktyg om min rumskollega inte visade mig Erlang i mitten på 90 talet. Alla går väl att konvertera. Det är väl bra i alla fall att förstå att statisk typning är en bra metod att förenkla programmering. Vi tyckert det finns bättre sätt.

Det är inte dåligt. Du kan skriva bra kod i Perl. Mycket handlar om vilket folk du jobbar med. Rewrite from scratch kan vara lite farligt dock.

Jag gillar TypeScript. Calva är mestadels TS och jag trivs fint med det. Ju mer jag fattat av Clojure, desto bättre blir min TS-kod.

Min kommentar handlar mer om min bild av den där ägaren. Han köper ett system som fungerar väl, där utvecklarna är nöjda och tycker saker fungerar bra. Då bestämmer han att de ska skriva om allt med annan teknik för att han har en annan, mycket mindre välinformerad uppfattning. Arrogans i kvadrat. Jag kan ha helt fel, men jag tror från det jag vet hittills att det är att kasta vatten på en gås.

Jag kallar honom inte för en idiot, men han verkar vara en idiot. 😃

Jag uppfattar situationen också som att kasta vatten på en gås..

Eftersom jag är väldigt felbar har jag ofta fel. Speciellt om andra personer. Tycker det kan vara em mycket bra övning i retorik att försöka göra ett mycket bra case och se om det hjälper.

En annan sak du nämnde i tråden, @U0D1EU0EL, lojalitet. Min erfarenhet (jag är ändå 55 år och har hunnit skaffa mig en del sådant) är att lojalitet mot ett företag är farligt för en själv. Lojalitet mot en produkt man tror på är lite bättre, men det är ändå sig själv man behöver vara mest lojal mot när man har med företag att göra. Medan man är anställd bör man göra sitt allra bästa i allt, och bete sig med stor lojalitet mot det man håller på med och de man gör det tillsammans med. Men när saker dras tills sin spets behöver man komma ihåg att den enda som kommer bevaka ens egna intressen kommer vara man själv och kanske någon extra juste kollega. Företaget kommer vara lojalt mot sina ägare.

Svårt att vara vara lojal mot ett bolag eftersom du kan råka tillhöra fel faktion om det visar sig att maktstrukturer ändras. Håller med om att det är viktigt att försöka göra sitt bästa och vara juste kollega.

Jupp. Själv har jag svårt att stänga av den där lojaliteten. Den kommer liksom automatiskt med att jag engagerar mig. Jag har fått lära mig den hårda vägen att försöka ha lite kontroll på den. Styra den så att den hjälper mig och företaget, och inte låta den gå ut över mig själv.

"Ju mer jag fattat av Clojure, desto bättre blir min TS-kod" är en pitch jag använt mig av många gånger när jag ska lära någon FP. "Du kommer bli en mycket bättre Java programmerare om du lär dig lite Haskell.", och stoppat boken "Learn you a Haskell for great good" i handen på vederbörande. Tålmodighet och lojalitet tror jag är stark bland de flesta som väljer att att införa ett språk som Clojure. Man ser ett sätt skriva kod som man tycker löser väldigt många problem, problem som de ser med andra tekniker. Man vill verkligen väl och tar jobbiga fighter för att få det genomfört. Du faller lätt offer med tålmodighet och lojalitet. Man står lätt kvar, snyting efter snyting tills man inte har något mer att ge.

Tack kamrater för er input, och framför allt all er omtanke. Jag beskrev ett helt fiktivt system. Ett system som jag själv skulle göra om jag skulle göra ett enkelt web system i Clojure. Jag har jobbat med några Clojure system sedan Clojure var ungt, sedan 1.1. men har där i mellan också kört andra uppdrag, Java, C# och F#. Att använda Datomic var en riktigt game-changer för mig. Har väl aldrig gillat SQL, utan har tidigare haft en förmåga att använda key value stores när jag får välja själv. Jag tycker det är irriterande med tjocka React wrappers som tenderar att bli som ramverk. Scenariot att man vill skriva om fullt fungerande Clojure system har jag råkat ut för flera gånger, speciellt under de första åren. Trots att jag tycker det är både roligt och relativt enkelt att låra folk Clojure, så har jag misslyckats att skapa trygghet. Nu har jag nyligen sett andra råka ut för problematiken. Jag upplever det frustrerande och fiskar efter material till en eventuell föreläsning. Hur förklarar man för lekmannen som känner sig otrygg med Clojure-system. Efter som jag tycker det är "The shit" är det svårt vara konkret. Det är ju så självklart för mig att det är "The shit". Sen tycker jag det är roligt med imperativt också, speciellt på lite lägre nivå. Men jag rekomenderar generellt Clojure/Datomic till enterprise system. Eftersom några av er reagerat med sådan omtanke har jag misslyckat med att beskriva att det var ett fiktivt system. Ber er om ursäkt för det, och tackar er för all er omtanke. Den värmer ❤️ /Stefan

Sen in i tråden men jag tror Janet skulle kunna referera till tex javas Spring-ramverk vars konfiguration av olika komponenter ju mer och mer blir ett eget språk, men kodat i XML. Logbacks konfigurationsfiler i XML blir liknande. Där kan jag hålla med om att det plötsligt blir väldigt många obegripliga options att ratta på, som ökar risken för fel. Men det större problemet där är ju att java saknar rimligt enhetliga sätt att läsa in rika trädade datastrukturer och sedan arbeta med dem.

I övrigt tror jag det enda som fungerar när ledningen får fixa idéer kring teknikval att lämna över det till dem som nu vill bygga det nya, och låta det gamla skeppet gå i kvav. Men naturligtvis beskriva att det nuvarande systemet har en lång rad detaljer som tagit lång tid att arbeta fram, och att man naturligtvis gärna försöker lämna över dessa till de nya utvecklarna. Men överlag: beskriv vad som finns, just nu. Det är lätt att tänka att ett visst system är ganska enkelt, för att det är enkelt på ytan, när det i själva verket är tämligen komplicerat. Se till att de nya utvecklarna, eller de med idéerna, på ett seriöst sätt tar sig an det befintliga systemet samt möjligheterna att anpassa systemet.

Ja @UQY3M3F6D. Det var min tanke också. Men Janet är ju en erfaren Clojurist, så det skulle ju också kunna vara kritik mot data orientering i Clojure, mer som vi tänker det.

SQL-databaser gör ju, genom sin mer rigida tabellstruktur det svårare att lägga till ytterligare fält i datat, vilket är en kostnad.

...precis på samma sätt som statiskt typade system gör det svårare att förändra typer, pga "rigiditet".

På sätt och vis kan jag väl hålla med om att det finns lösningar i Clojure, tex ramverket pedestals konfiguration, som wrappar webservern Jettys konfiguration och att den mappningen till slut blir ganska rörig och svår att dokumentera. Det går att hjäpa till att lösa det med tex spec eller malli, förstås. Typning missbrukas väldigt ofta som valideringsmekanism, och det är olyckligt.

Om det inte var så svårt att implementera en väl fungerande webserver skulle kanske Pedelstal, eller hur man skulle vilja ha en webserver, se annorlunda ut, Att diskutera konfiguration av en wrapper kanske inte är rättvist, om man nu vill kritisera dataorienterat i Clojure

Jag tänker att söka utsagan om att systemfel koncentreras till konfigurationen kan vara en felaktig observation. Om de delarna lösts med kod i stället kanske det hade varit fler fel i systemet.

Tack @U0ETXRFEW! "Solving Problems the Clojure Way" var en riktigt pedagogisk föreläsning att ta inspiration från. Den är ju gammal som gatan, så tråkigt att jag missat den. Men nu är ordningen återställd.. Tack

Å så refererar Rafal till Data oriented som data driven 🙂

Jag har gått från att prata om repl drivet till att prata om interaktiv live programmering direkt mot programmet när du kör